(aws-cdk): IAM role created by CDK Bootstrap is not following AWS best practices

[alexbaileyuk]

What is the problem?

Security Hub best practices suggest that IAM roles should not be given encrypt/decrypt permissions to all KMS keys (source).

The deployment role created by CDK bootstrap does not meet this criteria.

Reproduction Steps

Run cdk bootstrap and check the role policy on the deployment role (cdk-hnb659fds-deploy-role-787743944430-eu-west-1).

What did you expect to happen?

The bootstrap process should generate roles which conform to AWS best practices.

What actually happened?

The CDK bootstrap creates an IAM policy which contains a statement which looks like the following:

        {
            "Condition": {
                "StringEquals": {
                    "kms:ViaService": "s3.eu-west-1.amazonaws.com"
                }
            },
            "Action": [
                "kms:Decrypt",
                "kms:DescribeKey",
                "kms:Encrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "PipelineCrossAccountArtifactsKey"
        },

This is therefore not following the best practice control guidelines within Security Hub which are proposed by AWS.

CDK CLI Version

2.15.0 (build 151055e)

Framework Version

No response

Node.js Version

16.13.1

OS

Ubuntu

Language

Typescript, Python, .NET, Java, Go

Language Version

No response

Other information

Based on the template file (packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml) I believe that this can be resolved by changing the PipelineCrossAccountArtifactsKey statement in the DeploymentActionRole to use a single KMS resource instead of *.

For example:

              - Sid: PipelineCrossAccountArtifactsKey
                # Use keys only for the purposes of reading encrypted files from S3.
                Effect: Allow
                Action:
                  - kms:Decrypt
                  - kms:DescribeKey
                  - kms:Encrypt
                  - kms:ReEncrypt*
                  - kms:GenerateDataKey*
                Resource: "*"
                Condition:
                  StringEquals:
                    kms:ViaService:
                      Fn::Sub: s3.${AWS::Region}.amazonaws.com

could be updated to:

              - Sid: PipelineCrossAccountArtifactsKey
                # Use keys only for the purposes of reading encrypted files from S3.
                Effect: Allow
                Action:
                  - kms:Decrypt
                  - kms:DescribeKey
                  - kms:Encrypt
                  - kms:ReEncrypt*
                  - kms:GenerateDataKey*
                Resource: "arn:aws:kms:*:*:alias/SOME_ALIAS_NAME"
                Condition:
                  StringEquals:
                    kms:ViaService:
                      Fn::Sub: s3.${AWS::Region}.amazonaws.com

However, I do not know enough about the internal working of the CDK pipelines to understand if this could use an alias. Perhaps there's another way to achieve this?

[rix0rrr]

The Condition makes it so that the role does not have permissions to all keys. It only has permissions to keys that protect data in S3 buckets that the role is allowed to read, and that the KMS key itself allows permission for using its key policy.

Security Hub's finding seems a bit overeager here.

[alexbaileyuk]

The Condition makes it so that the role does not have permissions to all keys. It only has permissions to keys that protect data in S3 buckets that the role is allowed to read, and that the KMS key itself allows permission for using its key policy.

Security Hub's finding seems a bit overeager here.

You're right. Security Hub is often a little over jealous in it's assessments and it often misses additional information like the conditions. However, I think currently that key could be used to encrypt data in any S3 bucket within the account. It wouldn't be hard for someone to use it incorrectly on another bucket.

Definitely not a huge security risk but it's not ideal having every account using the CDK being non-compliant with the foundational checks in Security Hub.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[alexbaileyuk]

Whilst this has had little attention in over a year, there have been two duplicates opened showing it has affected other users as well.

I agree there is no critical security risk here, for companies using CDK and Security Hub, this is a pain to have to manage.

With AWS continuing to push Security Hub and related features, it makes more and more sense that the CDK conforms to best practices described there.

[guero235]

Ran into this too. Any remediation steps?

[Mattias-]

Solved in #24588
Upgrade to CDK CLI 2.70.0 and run cdk bootstrap to update the IAM policy.

[jeffgardnerdev]

@Mattias- I'm still getting a failure on this Security Hub rule after upgrading to CDK CLI 2.72.0 and re-running cdk bootstrap.

I can see that the IAM policy for the role has been updated with the changes made in the PR:

{
    "Condition": {
        "StringEquals": {
            "kms:ViaService": "s3.us-east-1.amazonaws.com"
        }
    },
    "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:Encrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*"
    ],
    "Resource": [
        "arn:aws:kms:*:<account id>:*"
    ],
    "Effect": "Allow",
    "Sid": "PipelineCrossAccountArtifactsKey"
}

but the compliance status is still showing as failed. Does this change actually resolve the Security Hub finding?

[Mattias-]

@Mattias- I'm still getting a failure on this Security Hub rule after upgrading to CDK CLI 2.72.0 and re-running cdk bootstrap.

I can see that the IAM policy for the role has been updated with the changes made in the PR:

{
    "Condition": {
        "StringEquals": {
            "kms:ViaService": "s3.us-east-1.amazonaws.com"
        }
    },
    "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:Encrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*"
    ],
    "Resource": [
        "arn:aws:kms:*:<account id>:*"
    ],
    "Effect": "Allow",
    "Sid": "PipelineCrossAccountArtifactsKey"
}

but the compliance status is still showing as failed. Does this change actually resolve the Security Hub finding?

It did for me.
You can trigger a re-eval of the rule in AWS Config or just wait.

[jeffgardnerdev]

It's been a few days, and I re-evaluated the rule in Config just in case, but it is still showing as non-compliant.

I wonder if it has to do with the fact that in my case the bootstrap stack has a trusted account so the resource ARN in this statement has another account ID in it. It would be nice if we could see the source code behind the managed Config rule so we could see exactly what it is checking for.

[jeffgardnerdev]

Had to table this for a bit and was able to come back to it today.

I played around with the policy by changing the resource and seeing if it would pass the compliance check. Each time I confirmed that the compliance check was reevaluated by checking the "Last successful detective evaluation" field on the rule.

I tried the following permutations:

arn:aws:kms:*:<trusted account id>:*
arn:aws:kms:<region>:<trusted account id>:*
arn:aws:kms:<region>:<target account id>:*
arn:aws:kms:<region>:<trusted account id>:<dummy key ID>

The only one that passed was the last, where I explicitly declared a key ID. All others failed the compliance check.

Not sure why this isn't working for me while it apparently works for others. Is there something I'm missing?

I do use CDK Pipelines which is why I have the trusted account. I'm unsure which key I would use even if I hardcoded it in the policy--the trusted account seems to be using an AWS-managed key as I don't see any CMKs in that account.

Any guidance would be appreciated!

cc: @rix0rrr as the PR author

[tobi2736]

As the issue is still open, I wonder if this problem still exists (even the comments indicate that it should be fixed)?

I am using AWS CDK 2.161.1 (build 0a606c9) and bootstrapped a brand new AWS account yesterday.

AWS Security Hub brings up this finding:
[KMS.2 IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys])
for the CDK IAM role:
cdk-hnb659fds-deploy-role-123456789000-eu-west-1

This is the relevant snipped from the policy:
{ "Condition": { "StringEquals": { "kms:ViaService": "s3.eu-west-1.amazonaws.com" } }, "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource": "*", "Effect": "Allow", "Sid": "PipelineCrossAccountArtifactsKey" }

I am bit confused now...

[HBobertz]

CDK Core team member checking in. @tobi2736 seems to have found a security finding than the one originally reported. I tried this on my own account with cdk version 2.166.0 to see if I might get finding KMS.1 or KMS.2 and wasn't able to get either error associated with the bootstrap. I also manually verified my bootstrap generated deploy-role and didn't see any of the relevant "kms:Encrypt", "kms:ReEncrypt*", etc... permissions. I think we can probably close this but I'll keep it open for now because @tobi2736 was able to find these permissions and perhaps there's some config option creating this.

EDIT: correction I put 1.166 but I meant 2.166

[alexbaileyuk]

@HBobertz I do not think we should close issues based on version 1.166.0. CDK version 1 is not supported any more and the reported version was version 2.15.0.

[HBobertz]

@HBobertz I do not think we should close issues based on version 1.166.0. CDK version 1 is not supported any more and the reported version was version 2.15.0.

My apologies I meant 2.166, I corrected my comment

[damshenas]

I am deploying CdkBootstrapVersion 25 using the exported template from cdk cli. And I get KMS.2 security finding.

I think the following is relevant IAM policy:

  DeploymentActionRole:
      Policies:
        - PolicyDocument:
            Statement:
              - Sid: PipelineCrossAccountArtifactsKey
                Effect: Allow
                Action:
                  - kms:Decrypt
                  - kms:DescribeKey
                  - kms:Encrypt
                  - kms:ReEncrypt*
                  - kms:GenerateDataKey*
                Resource: "*"
                Condition:
                  StringEquals:
                    kms:ViaService:
                      Fn::Sub: s3.${AWS::Region}.amazonaws.com

I opt in for using AWS Managed Key and I fixed this KMS.2 by following change:

  DeploymentActionRole:
      Policies:
        - PolicyDocument:
            Statement:
              - Sid: PipelineCrossAccountArtifactsKey
                Effect: Allow
                Action:
                  - kms:Decrypt
                  - kms:DescribeKey
                  - kms:Encrypt
                  - kms:ReEncrypt*
                  - kms:GenerateDataKey*
                Resource: 
                  Fn::Sub: arn:aws:kms:${AWS::Region}:${AWS::AccountId}:key/*
                Condition:
                  StringEquals:
                    kms:ViaService:
                      Fn::Sub: s3.${AWS::Region}.amazonaws.com
                    kms:ResourceAliases:
                      Fn::Sub: alias/aws/s3

Hope this helps someone to save some time.