Create a way to generate Service Linked Roles
Service Linked Roles can't be created in a Stack format. They are created automatically by cdk if they don't exists, but you can't use them in other stacks.
Use Case
- Create a custom Service Linked Role (SLR) for
/aws-service-role/autoscaling.amazonaws.com/with custom suffix - Write ARN to SSM
- Create a KMS CMK Key and grant the Service Linked Role Privileges in KMS Policy.
- Create a Auto Scaling Group with the custom Service Linked Role
On Stack Deleting:
- Delete Auto Scaling Group
- Delete KMS Key
- Delete Service Linked Role
Proposed Solution
- The Metadata of a Stack should hold the Information and state of the Service Linked Role
- Create some kind of pre-Script for a CDK Stack, that:
- Checks if the key exists
- Checks the State of the SLR with State in the Stack Meta Data
- Fails if this States ad no consistent
- Creates a new SLR if it does not exist and wasn't created with the Stack before
- Supply the SLR ARN and Name back to the rest of the Stack, so you can use these Parameters to write to SSM Parameter
This Issues uses ASG as an Use Case, but ist much more general.
Just think of the default Roles:
- arn:aws:iam::
:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS - arn:aws:iam::
:role/aws-service-role/ssm.amazonaws.com/AWSServiceRoleForAmazonSSM
Most users will create these Roles when clicking around and testing in AWS manually. For users not using KMS CMK these roles don't need other right.
If you use KMS CMK these Roles need to bee added to KMS CMK Key Policy and in this case the Policy will throw an error, if the Principal of the Policy Statement doesn't exit (Policy contains a statement with one or more invalid principals).
The stacks in CDK should be reproducible, so ther must be a way to create Service Linked Roles with Custom Suffix on Roleout of a CDK Stack and these Roles should disappear, when the Stack is deleted.
@rix0rrr Any thoughts?
++
Actually, to do that I've created a custom resource with a "lambda.SingletonFunction" to create or revoke this Grant; not very integrated... Before that, you need to import the Arn of the CMK; and the Key only, the Grant can't be created with an Alias; so the other difficulty is to get the Arn of the CMK, created on another account.
No native solution for that too... Need to create an SSM Parameter from a "cdk [...] --outputs-file" before with the outputs wanted. Really need a feature like a "resolver" cross-accounts/stacks to do that in CDK core.
Hi @coding-jj,
Thanks for opening this issue! After reviewing the details, we found some other discussions that may be duplicates or closely related:
Potential Duplicate Issues
- #4108: Both issues address the fundamental limitation that service-linked roles cannot be properly created and managed within the CDK stack lifecycle. The current issue elaborates with specific requirements for custom suffixes, metadata tracking, and integration with KMS CMK key policies. Both focus on the same technical problem where service-linked roles created automatically by AWS services aren't tracked in CloudFormation stacks, causing issues with cross-stack references and stack deletion.
Related Issues
-
#569: Both issues address the inability to create service-linked roles within CDK stacks. While this issue identifies the basic problem of lacking a mechanism for service-linked role creation, the current issue builds upon this with a comprehensive solution including stack metadata tracking, custom suffixes, SSM parameter storage, and proper lifecycle management for clean stack deletion.
-
#4108: Both issues address the fundamental limitation that service-linked roles cannot be properly created and managed within the CDK stack lifecycle. The current issue elaborates with specific requirements for custom suffixes, metadata tracking, and integration with KMS CMK key policies. Both focus on the same technical problem where service-linked roles created automatically by AWS services aren't tracked in CloudFormation stacks, causing issues with cross-stack references and stack deletion.
-
#4467: Both issues involve managing service-linked roles for AutoScaling Groups, particularly when using KMS CMK keys. This issue focuses specifically on exposing the ServiceLinkedRoleARN property in the AutoScalingGroup construct, while the current issue proposes a broader framework for creating and managing custom service-linked roles across different AWS services. They share the same underlying use case of needing to reference custom service-linked roles in KMS key policies.
This message was generated automatically to help connect related conversations and improve discoverability.
If you feel this issue brings new or distinct information, feel free to add a comment to keep it open. Otherwise, we'll close this issue in 7 days if we don't recieve a response to help keep discussions consolidated.
Please react with 👍 or 👎 to let us know if this response was helpful!
Thank you for helping improve CDK! 🙌
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.