(core): CDK 2.16 Cross stack output removed regardless of stackRelativeExports flag setting
See original GitHub issueWhat is the problem?
Stack A creates an IAM user, assigns an access key to the user and provides the AccessKey as a property of the Stack.
Stack B creates a Fargate task with environment variables set to the AccessKey.ref and AccessKey.secretAccessKey that were created in Stack A.
Pre CDK2, the appropriate outputs and references would be created in the CloudFormation templates. Post CDK 2 upgrade, the outputs are being removed as well as the references.
Reproduction Steps
Full cdk application examples are located here: https://github.com/rcollette/CDK1-Outputs-Issue-SCCE https://github.com/rcollette/CDK2-Outputs-Issue-SCCE
Output templates are attached. CDK1Templates.zip cdk2templates.zip
What did you expect to happen?
An output should be created for the accessKey in Stack A and the output should be referenced in Stack B
What actually happened?
CDK is removing the outputs and references that were present in CDK 1.x
Stack pdx-PdxApi-users-dev
Parameters
[+] Parameter BootstrapVersion BootstrapVersion: {"Type":"AWS::SSM::Parameter::Value<String>","Default":"/cdk-bootstrap/hnb659fds/version","Description":"Version of the CDK Bootstrap resources in this environment, automatically retrieved from SSM Parameter Store. [cdk:skip]"}
Outputs
[-] Output ExportsOutputRefDeliveriesSignerAccessKey4F197D7B: {"Value":{"Ref":"DeliveriesSignerAccessKey"},"Export":{"Name":"pdx-PdxApi-users-dev:ExportsOutputRefDeliveriesSignerAccessKey4F197D7B"}}
[-] Output ExportsOutputFnGetAttDeliveriesSignerAccessKeySecretAccessKey55F19EC7: {"Value":{"Fn::GetAtt":["DeliveriesSignerAccessKey","SecretAccessKey"]},"Export":{"Name":"pdx-PdxApi-users-dev:ExportsOutputFnGetAttDeliveriesSignerAccessKeySecretAccessKey55F19EC7"}}
Stack pdx-PdxApi-dev
IAM Statement Changes
βββββ¬βββββββββββββββββββββββββ¬βββββββββ¬βββββββββββββββββ¬ββββββββββββββββββββββββββββββββββ¬ββββββββββββ
β β Resource β Effect β Action β Principal β Condition β
βββββΌβββββββββββββββββββββββββΌβββββββββΌβββββββββββββββββΌββββββββββββββββββββββββββββββββββΌββββββββββββ€
β + β ${PdxApi-TaskRole.Arn} β Allow β sts:AssumeRole β Service:ecs-tasks.amazonaws.com β β
βββββ΄βββββββββββββββββββββββββ΄βββββββββ΄βββββββββββββββββ΄ββββββββββββββββββββββββββββββββββ΄ββββββββββββ
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)
Parameters
[+] Parameter BootstrapVersion BootstrapVersion: {"Type":"AWS::SSM::Parameter::Value<String>","Default":"/cdk-bootstrap/hnb659fds/version","Description":"Version of the CDK Bootstrap resources in this environment, automatically retrieved from SSM Parameter Store. [cdk:skip]"}
Resources
[-] AWS::IAM::Role TaskRole30FC0FBB destroy
[+] AWS::IAM::Role PdxApi-TaskRole PdxApiTaskRole3B6A8344
[~] AWS::ElasticLoadBalancingV2::TargetGroup PdxApiLB/PublicListener/ECSGroup PdxApiLBPublicListenerECSGroup2F538E86
ββ [+] TargetGroupAttributes
ββ [{"Key":"stickiness.enabled","Value":"false"}]
[~] AWS::ECS::TaskDefinition PdxApi/TaskDef PdxApiTaskDef6E809282 replace
ββ [~] ContainerDefinitions (requires replacement)
β ββ @@ -147,18 +147,6 @@
β [ ] ]
β [ ] ]
β [ ] }
β [-] },
β [-] {
β [-] "Name": "DeliveriesBucketConfiguration__SignerAccessKey",
β [-] "Value": {
β [-] "Fn::ImportValue": "pdx-PdxApi-users-dev:ExportsOutputRefDeliveriesSignerAccessKey4F197D7B"
β [-] }
β [-] },
β [-] {
β [-] "Name": "DeliveriesBucketConfiguration__SignerSecretAccessKey",
β [-] "Value": {
β [-] "Fn::ImportValue": "pdx-PdxApi-users-dev:ExportsOutputFnGetAttDeliveriesSignerAccessKeySecretAccessKey55F19EC7"
β [-] }
β [ ] }
β [ ] ],
β [ ] "Essential": true,
ββ [~] TaskRoleArn (requires replacement)
ββ [~] .Fn::GetAtt:
ββ @@ -1,4 +1,4 @@
[ ] [
[-] "TaskRole30FC0FBB",
[+] "PdxApiTaskRole3B6A8344",
[ ] "Arn"
[ ] ]
CDK CLI Version
2.16.0 (build 4c77925)
Framework Version
2.15
Node.js Version
16.14.0
OS
macOS 12.1
Language
Typescript
Language Version
4.6.2
Other information
The pre-upgrade CDK version is 1.106.1
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (5 by maintainers)
I believe the answer here is βnoβ, because if it worked, it was by accident. This was never documented behaviour.
@rix0rrr - Shouldnβt a new behavior such as this be documented in the breaking changes log at the very least?