[cli] deploy cannot specify S3 SSE for asset upload

[CaseyBurnsSv]

Reproduction Steps

1. cdk bootstrap with legacy bootstrap, provide kms key id as param
2. have a SCP setup that denies s3:PutObject if s3:x-amz-server-side-encryption is missing
3. create a CDK app that provisions a lambda asset
4. execute cdk deploy
5. deploy fails and receive Access Denied error

What did you expect to happen?

i expect CDK deploy to explicitly use the kms key i specified in the bootstrap when uploading assets.

What actually happened?

cdk deploy does not provide SSE and the deploy fails with Access Denied.
It appears to be relying on the S3 default encryption instead of specifying the SSE options to the S3 put object request.

Environment

• CLI Version : 1.71.0
• Framework Version:
• Node.js Version: v12.16.1
• OS : Windows 10
• Language (Version): Python 3.8.5

Other

---

This is 🐛 Bug Report

[rix0rrr]

It appears to be relying on the S3 default encryption instead of specifying the SSE options to the S3 put object request.

That is correct, it does rely on default encryption. It seems convenient and logical to me to separate the upload action from the encryption action, which we can easily do in this way.

Can you tell me why you need it to work differently?

[CaseyBurnsSv]

It appears to be relying on the S3 default encryption instead of specifying the SSE options to the S3 put object request.

That is correct, it does rely on default encryption. It seems convenient and logical to me to separate the upload action from the encryption action, which we can easily do in this way.

Can you tell me why you need it to work differently?

I think it should be consistent with other AWS tooling like sam deploy and aws cloudformation deploy which allow the option of specifying the encryption config used by files uploaded to s3.

Without this option it may make CDK unusable in highly regulated financial services organizations like the one I work for.

[rix0rrr]

I probably just don't have enough domain knowledge here.

Can you explain to me why a default encryption setting on the bucket is not good enough to achieve your encryption at rest requirements?

[CaseyBurnsSv]

the issue is that we have organizational service control policies in place that Deny PutObject requests that do not explicitly specify the x-amz-server-side-encryption header. this is a security control that is commonly applied to enforce the use of encryption across an AWS Organization. relying on default s3 encryption does not specify the required headers.

we need the option of specifying the encryption method and key in the PutObject request sent by CDK.

for example the AWS CLI command aws cloudformation deploy allows us to specify this with the --kms-key-id parameter. and sam deploy provides the same parameter.

[rix0rrr]

So if I'm understanding correctly, it's not because of any functional reason, right?

It's not because with default encryption you couldn't achieve the desired end result of files being encrypted with a particular KMS key.

It's because your current set of security policies misses and rejects this particular kind of configuration, even though it would be a valid setup that would achieve the desired end result.

[CaseyBurnsSv]

that is correct. this preventive security control (SCP) is on the PutObject request to S3, not on the state of the bucket itself.

[JanWe92]

I reproduced this behaviour and we have the same issue. We need the same SCP settings for the staging bucket, which we modified via the bootstrap template, but we cannot deploy the defined stack because of an "Access Denied" failure.

[hmcmanus]

I've just come across the same issue today. Any workarounds on this one that people have tried?

[openfinch]

Adding onto this, this is a strange feature to leave out considering it exists in other AWS-provided tools. This is a fairly common SCP in larger environments.

[Ettery]

We have the same problem - enterprise level requirement to specify the header(s) as a part of the approach to securing all S3 buckets. There is no way to enforce that all S3 buckets in an account are created with SSE switched on so this approach of enforcing headers on the s3:PutObject call is Amazon's recommended approach for organisations wanting to enforce encryption at rest.

End result is that CDK is unable to deploy assets. We'd like to move from Terraform to CDK, but this is stopping us.

[cagdas-carbon]

Are there any plans on adding an argument to cdk deploy to fix this?

[ArlindNocaj]

@CaseyBurnsSv
It seems that CDK 2.0 has additional features regarding bootstrapping (Amazon S3 bucket, AWS KMS key, SSM parameter for versioning). Could this be helpful in resolving the above issue? https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html#bootstrapping-templates

It would be great if someone with the infrastructure setup could evaluate it.
@rix0rrr Maybe someone from your team could investigate if there is a workaround with CDK 2.0 ?

[cagdas-carbon]

@ArlindNocaj

I tried with the new style bootstrapping. There is a support for SSM parameter for bootstrapping but the issue is the deployment (deploy command) doesn't support the same. The problem occurs when it tries to upload the template to S3 before the deployment (When it's larger than 50kb).

I didn't take a deeper look but potentially the problem is the S3 upload here does not support the encryption flag.

[NukaCody]

You can customize the bootstrap that refers to the asset bucket (where assets go to) (docs)

cdk bootstrap --show-template > bootstrap.yml

Then modify the bucket policy to fit your organization SCP

A (untested) example would be something like below.

  StagingBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket:
        Ref: StagingBucket
      PolicyDocument:
        Id: AccessControl
        Version: "2012-10-17"
        Statement:
          - Sid: AllowSSLRequestsOnly
            Action: s3:*
            Effect: Deny
            Resource:
              - Fn::Sub: ${StagingBucket.Arn}
              - Fn::Sub: ${StagingBucket.Arn}/*
            Condition:
              StringNotEquals:
                "s3:x-amz-server-side-encryption": "aws:kms"
            Principal: "*"

I don't have an org with the SCP set up so I would double check that the yml works with your respective org SCPs.

This type of modification shouldn't break the bootstraping contract.

So then you can deploy via cdk bootstrap --template bootstrap.yaml

EDIT:

The example above uses aws:kms, which means it could potentially break the file publising role if that role does not have access to the respective KMS key......so you may require additional modification if you go down that path. If not needed to meet your orgs SCP. It may be easier to go down the SSE-S3 path as mentioned in the earlier linked blog

[ArlindNocaj]

I evaluated this approach by adding the following Staging bucket policy and boostraping with cdk bootstrap --bootstrap-kms-key-id 1234key --template bootstrap.yml

  StagingBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket:
        Ref: StagingBucket
      PolicyDocument:
        Id: AccessControl
        Version: "2012-10-17"
        Statement:
          - Sid: DenyIncorrectEncryptionHeader
            Action: s3:PutObject
            Effect: Deny
            Resource:
              - Fn::Sub: ${StagingBucket.Arn}
              - Fn::Sub: ${StagingBucket.Arn}/*
            Condition:
              StringNotEquals:
                s3:x-amz-server-side-encryption: "aws:kms"
            Principal: "*"
          - Sid: DenyUnEncryptedObjectUploads
            Action: s3:PutObject
            Effect: Deny
            Resource:
              - Fn::Sub: ${StagingBucket.Arn}
              - Fn::Sub: ${StagingBucket.Arn}/*
            Condition:
              "Null":
                  "s3:x-amz-server-side-encryption": "true"              
            Principal: "*"

While this makes sure that the S3 cdk staging bucket does have the right policies, the cdk deploy command does not seem to support uploading to S3 using a kms-key and the problem still persists.

[bartdevriendt]

We need this as well. In our enterprise environment we require every file uploaded to S3 to be encrypted. In terraform this is solved by defining the encryption on the backend:

backend "s3" {
    bucket = "..."
    region = "eu-west-1"
    key = "..."
    kms_key_id = "...."
    encrypt = true
  }

This sets the x-amz-server-side-encryption header.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.