(aws-eks-v2-alpha): (tags not propagating to the construct custom resources and being blocked)
Describe the feature
Custom resources created by the Cluster construct and other constructs need to inherit the tags of the cluster and stack if they are supplied.
Use Case
We have tag enforcement SCPs for Lambda and few other critical services. The Lambdas for the custom resources, such as OpenID Connect Provider and CFN Utils Provider are being blocked from being created because they do not have any tags so the deployment is failing when you use the property for alb_controller.
Proposed Solution
All custom resource providers (Lambdas) should inherit the tags of the construct that is being created.
Other Information
Here is a gist with the code to reproduce the situation: eks_stack
The only way to workaround currently is install the alb controller separately.
Acknowledgements
- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
AWS CDK Library version (aws-cdk-lib)
2.212.0a0
AWS CDK CLI version
2.1026.0
Environment details (OS name and version, etc.)
Windows 11
Hi @tomburge,
Thank you for reporting this issue. This is a valid concern regarding tag propagation in the EKS v2 alpha module.
Problem Confirmed: Custom resources created by EKS v2 alpha constructs (such as Lambda functions for the ALB Controller, KubectlProvider, and OIDC providers) do not automatically inherit tags from the parent cluster construct. This causes deployment failures when SCPs enforce mandatory tagging policies.
Root Cause: Custom resources create their own nested CloudFormation stacks, and CDK's tagging mechanism doesn't traverse into these nested stacks. Neither stack-level tags nor stack-level aspects can reach these resources.
Immediate Workaround: Apply aspects at the CDK App level to catch all Lambda functions across nested stacks:
import { Tags, Aspects, IAspect } from 'aws-cdk-lib';
import { Function } from 'aws-cdk-lib/aws-lambda';
import { IConstruct } from 'constructs';
class LambdaTagger implements IAspect {
constructor(private tags: { [key: string]: string }) {}
visit(node: IConstruct): void {
if (node instanceof Function) {
Object.entries(this.tags).forEach(([key, value]) => {
Tags.of(node).add(key, value);
});
}
}
}
// Apply to entire CDK app
Aspects.of(app).add(new LambdaTagger({
'Environment': 'production',
'Team': 'platform'
}));
Long-term Solution: We need to enhance the EKS v2 alpha module to automatically propagate cluster tags to all custom resource providers. This would involve modifying constructs like AlbController and ServiceAccount to inherit and apply tags from their parent cluster.
This is an important enhancement for organizations with strict tagging policies. We encourage community contributions to implement this feature!
Let me know if the workaround works for you.
Related Issues: #17533, #33196
Sorry this has taken so long for me to come back to.
The code in the gist is Python not Typescript so I might not be doing it right, but I was first getting an error about the Tag code on 293-294 so I commented that out.
Now I'm getting an error "an Aspect Object with a lower priority (added at -stack reference- with priority 500) was already invoked on this code.
I tried adding self.priority = 600 to the init class method, but I got the same error.