-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(CLI): We don't support attributes of the 'AWS::KMS::Key' resource #25418
(CLI): We don't support attributes of the 'AWS::KMS::Key' resource #25418
Comments
Thanks for reporting this and #25417, and for providing code that's easy to reproduce this with. It looks to me like this is only occurring within a Nested Stack. Eliminating the nested stack will allow hotswapping to succeed. There's likely some bug related to how we're processing the changeset when nested stacks are involved
|
Both of these errors are likely caused from cross stack references. For some reason these are getting picked up even though they're not changing. Maybe we haven't implemented the logic to resolve cfn parameter values when attempting to hotswap, but I'm not sure that would explain why the streamArn is getting caught when it's only used on the EventSourceMapping
|
…7195) This PR solves two problems when doing hotswap deployments with nested stacks. 1. Adding capabilities to evaluate CFN parameters of `AWS::CloudFormation::Stack` type (i.e. a nested stack). In this PR, we are only resolving `Outputs` section of `AWS::CloudFormation::Stack` and it can be expanded to other fields in the future. See https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-cloudformation.html#w2ab1c17c23c19b5 for CFN documentation around using Outputs ref parameters 2. If a template has parameters with default values and they are not provided (a value) by the parent stack when invoking, then resolve these parameters using the default values in the template. Partially helps #23533 and #25418 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The reason why this works if there's no nested stacks involved is that the function's
Then the @peterwoodworth is correct that the reason we're only seeing this for nested stacks is cross-stack references. Because it's a nested stack, the value of the This is expected behavior, as seemingly unexpected as it is. The actual error is that the |
One could argue that nested stack parameters should not always be evaluated, since they may be used in non-hotswappable resources. This is fair, but it wouldn't fix this particular case; the Key is being passed to a lambda, which is hotswappable. The lambda function is using that environment variable, since that's the only reason to include the key arn in the environment, so we have to evaluate the parameters at least if they're used in a hotswappable resource. |
### Issue # (if applicable) Closes #25418. ### Reason for this change KMS Keys cannot be referenced in hotswappable resources. CDK complains that this is a limitation: ``` Could not perform a hotswap deployment, because the CloudFormation template could not be resolved: We don't support attributes of the 'AWS::KMS::Key' resource. This is a CDK limitation. Please report it at https://github.com/aws/aws-cdk/issues/new/choose. ``` ### Description of changes Add KMS keys to the supported list of resource attributes for hotswapping. ### Description of how you validated changes Tests ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Describe the bug
--hotswap
deploy is not working on a Lambda function that has a KMS Key ARN obtained fromkey.keyArn
set as an environment for that function. The KMS key is created in a parent stack while the Lambda function is created in a nested stack. The Lambda function simply references the KMS key ARN in its environment variables and the KMS key has not been changed at all when attempting to do the hotswap deploy.Expected Behavior
Hotswap deploy of the modified Lambda function source code, which was the only thing modified before attempting to do the
cdk deploy --hotswap TempProjectStack
command.Current Behavior
Hotswap deploy fails and I get the following error:
Reproduction Steps
TypeScript files to reproduce on a new project
bin/cdk.ts
lib/temp-project-stack.ts
src/index.js
Possible Solution
Allow the KMS Key ARN string returned from
key.keyArn
to be used in an environment variable for a Lambda function. Using something likekey.keyId
did seem to work in some quick testing I did, but we would prefer to use the full ARN string returned fromkey.keyArn
rather than have to build our own ARN or store the ARN in something like ParameterStore. We aren't trying to deploy modified KMS keys with the--hotswap
deploy, just looking to update the Lambda source code that has the key ARN set as an environment variable.Additional Information/Context
cdk diff
of the project after I modify the Lambda function's source code before trying thecdk deploy --hotswap TempProjectStack
command:CDK CLI Version
2.73.0
Framework Version
No response
Node.js Version
v18.15.0
OS
Ubuntu 20.04 LTS
Language
Typescript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: