KMS: Passing in admins when creating key allows actions = kms:* for account root

[ecs-jnguyen]

Describe the bug

When I am passing in the admins parameter to the kms key, I still see the default key policy that allows Action: kms:* for the account root.

Expected Behavior

I expect for there to only be 1 statement that only allows my specified role (TheRole) to have access to the kms key

Resources:
  TheKeyName5734F6E4:
    Type: AWS::KMS::Key
    Properties:
      KeyPolicy:
        Statement:
          - Action:
              - kms:CancelKeyDeletion
              - kms:Create*
              - kms:Delete*
              - kms:Describe*
              - kms:Disable*
              - kms:Enable*
              - kms:Get*
              - kms:List*
              - kms:Put*
              - kms:Revoke*
              - kms:ScheduleKeyDeletion
              - kms:TagResource
              - kms:UntagResource
              - kms:Update*
            Effect: Allow
            Principal:
              AWS: arn:aws:iam::123456789012:role/TheRole
            Resource: "*"
        Version: "2012-10-17"
    UpdateReplacePolicy: Retain
    DeletionPolicy: Retain
    Metadata:
      aws:cdk:path: DebugCdkStack/TheKeyName/Resource

Current Behavior

Currently this is the cloudformation template that is generated. You can see the first statement allows kms:* for the account root. The second admin policy is redundant because the first one allows everything for the root.

Resources:
  TheKeyName5734F6E4:
    Type: AWS::KMS::Key
    Properties:
      KeyPolicy:
        Statement:
          - Action: kms:*
            Effect: Allow
            Principal:
              AWS:
                Fn::Join:
                  - ""
                  - - "arn:"
                    - Ref: AWS::Partition
                    - ":iam::"
                    - Ref: AWS::AccountId
                    - :root
            Resource: "*"
          - Action:
              - kms:CancelKeyDeletion
              - kms:Create*
              - kms:Delete*
              - kms:Describe*
              - kms:Disable*
              - kms:Enable*
              - kms:Get*
              - kms:List*
              - kms:Put*
              - kms:Revoke*
              - kms:ScheduleKeyDeletion
              - kms:TagResource
              - kms:UntagResource
              - kms:Update*
            Effect: Allow
            Principal:
              AWS: arn:aws:iam::123456789012:role/TheRole
            Resource: "*"
        Version: "2012-10-17"
    UpdateReplacePolicy: Retain
    DeletionPolicy: Retain
    Metadata:
      aws:cdk:path: DebugCdkStack/TheKeyName/Resource

Reproduction Steps

        role = ArnPrincipal("arn:aws:iam::123456789012:role/TheRole")
        aws_kms.Key(
            self, id="TheKeyName", admins=[role]
        )

Possible Solution

When we specify admins during the kms key creation we should remove the default policy.

Additional Information/Context

No response

CDK CLI Version

2.67.0

Framework Version

No response

Node.js Version

v19.1.0

OS

mac

Language

Python

Language Version

python (3.10)

Other information

Another thing I noticed is that if I use ArnPrincipal("my role arn") it add "my role arn" into the key policy. However if I use aws_iam.Role.from_role_name(..., "my role name"), it will create an AWS::IAM::Policy and associate it to the role. I wasn't sure if this behavior should have its own issue or not.

[khushail]

Hi @ecs-jnguyen , its mentioned in the Readme doc for the KMS that you need to set FeatureFlag , please see the excerpt below-

In applications without the '@aws-cdk/aws-kms:defaultKeyPolicies' feature flag set and with trustedAccountIdentities set to false (the default), specifying a policy at key creation appends the provided policy to the default key policy, rather than replacing the default policy.

With that being said, could you please check if you have followed the same. Thanks

[ecs-jnguyen]

Thank you that answers my question!

Under the other information part of my post I noticed some behavior around using an IRole vs an IPrincipal with the add grant methods. Do you know if this behavior is intended?

Another thing I noticed is that if I use ArnPrincipal("my role arn") it add "my role arn" into the key policy. However if I use aws_iam.Role.from_role_name(..., "my role name"), it will create an AWS::IAM::Policy and associate it to the role. I wasn't sure if this behavior should have its own issue or not.

[pahud]

Hi @ecs-jnguyen

When you grant access to an IAM role with iam.Role.fromRoleName(), which returns IRole, CDK essentially creates an IAM policy and associate this policy to the provided existing role. The KMS key policy will remain untouched.

  const roleFromName = iam.Role.fromRoleName(this, 'existing-role', 'my-existing-role');

  new kms.Key(this, 'Key', {
    admins: [roleFromName], 
  })

However, if you grant to an IAM principal with iam.ArnPrincipal(), which returns IPrincipal, CDK essentially will NOT create an iam policy, instead, it just adds a statement to the KMS key policy, which always comes with the key creation.

  const roleFromArn = new iam.ArnPrincipal('arn:aws:iam::123456789012:role/TheRole');

  new kms.Key(this, 'Key', {
    admins: [roleFromArn], 
  })

Please note IAM role and key policy are different, No AWS principal, including the account root user or key creator, has any permissions to a KMS key unless they are explicitly allowed, and never denied, in a key policy, IAM policy, or grant. See key policies in AWS KMS for more details.

You can try those properties and run cdk diff to see the difference and how it works in action.

I hope this helps clarify.

[pahud]

As this is not a relevant bug or feature request, I am converting this to discussion. Let me know if you have any further questions.