feat(cli): add ability to specify an external id for the deploy-role #15604
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added the ability to specify an external id for the deploy-role as part of the synthesizer config. this is similar to the existing functionality that allows specifying the external id for the image and file publishing roles
|
|
rix0rrr
added
the
pr-linter/exempt-readme
rix0rrr
approved these changes
Jul 16, 2021
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
TikiTDO
pushed a commit
to TikiTDO/aws-cdk
that referenced
this pull request
Aug 3, 2021
…ws#15604) added the ability to specify an external id for the deploy-role as part of the synthesizer config. this is similar to the existing functionality that allows specifying the external id for the image and file publishing roles In order to take advantage of this functionality you would need to customize the bootstrap template. To test this feature I customized the DeploymentActionRole in the bootstrap template to have the `AssumeRolePolicyDocument` as: ```yaml DeploymentActionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Statement: - Action: sts:AssumeRole Condition: StringEquals: sts:ExternalId: "my-external-id" Effect: Allow Principal: AWS: - Fn::Join: - "" - - "arn:" - Ref: AWS::Partition - :iam::1111111111111:root Version: "2012-10-17" ... RoleName: Fn::Sub: cdk-${Qualifier}-deploy-role-${AWS::AccountId}-${AWS::Region} ``` I then created a test stack that specified that external id: ```ts new CdkExternalIdTestStack(app, 'CdkExternalIdTestStack', { env: { account: '111111111111', region: 'us-east-2', }, synthesizer: new cdk.DefaultStackSynthesizer({ deployRoleExternalId: 'my-external-id', }), }); ``` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
hollanddd
pushed a commit
to hollanddd/aws-cdk
that referenced
this pull request
Aug 26, 2021
…ws#15604) added the ability to specify an external id for the deploy-role as part of the synthesizer config. this is similar to the existing functionality that allows specifying the external id for the image and file publishing roles In order to take advantage of this functionality you would need to customize the bootstrap template. To test this feature I customized the DeploymentActionRole in the bootstrap template to have the `AssumeRolePolicyDocument` as: ```yaml DeploymentActionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Statement: - Action: sts:AssumeRole Condition: StringEquals: sts:ExternalId: "my-external-id" Effect: Allow Principal: AWS: - Fn::Join: - "" - - "arn:" - Ref: AWS::Partition - :iam::1111111111111:root Version: "2012-10-17" ... RoleName: Fn::Sub: cdk-${Qualifier}-deploy-role-${AWS::AccountId}-${AWS::Region} ``` I then created a test stack that specified that external id: ```ts new CdkExternalIdTestStack(app, 'CdkExternalIdTestStack', { env: { account: '111111111111', region: 'us-east-2', }, synthesizer: new cdk.DefaultStackSynthesizer({ deployRoleExternalId: 'my-external-id', }), }); ``` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
1 task
mergify bot
pushed a commit
that referenced
this pull request
Sep 23, 2024
Allow passing [all STS options](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters) to assume role configuration for various CDK roles. > The following PR description focuses on Session Tags because it was originally the only option we wanted to add support to. After some thought, we decided to allow all available STS options via a transparent pass-through. ### Prerequisites - cdklabs/cloud-assembly-schema#33 - cdklabs/cdk-assets#40 ### Issue # (if applicable) Closes #26157 Fixes #22535 ### Reason for this change Enabling [ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) via STS session tags. From the [AWS docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html): > _“Session Tags are key-value pair attributes that you pass when you assume an IAM role or federate a user in AWS STS. You do this by making an AWS CLI or AWS API request through AWS STS or through your identity provider (IdP). When you use AWS STS to request temporary security credentials, you generate a session. Sessions expire and have [credentials](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html), such as an access key pair and a session token. When you use the session credentials to make a subsequent request, the [request context](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html#AccessPolicyLanguage_RequestContext) includes the [aws:PrincipalTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) context key. You can use the aws:PrincipalTag key in the Condition element of your policies to allow or deny access based on those tags”_ ### Description of changes The CDK creates [4 IAM roles](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html#bootstrapping-env-roles) during bootstrap. It then assumes these roles at various phases of the deployment. - [DeploymentActionRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L429): Assumed when invoking CloudFormation operations such as _Deploy_ and _DescribeStackEvents_. - [FilePublishingRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L275): Assumed when file assets are uploaded to the bootstrap bucket. - [ImagePublishingRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L298): Assumed when docker images are published to the bootstrap ECR registry. - [LookupRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L321): Assumed while performing context lookups. Each of these roles should be assumable with their own specific session tags, as they server different purposes. > Note: The [CloudFormationExecutionRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L536) is also created during bootstrap, but the CLI never assumes it, therefore it doesn't need session tags support. Session tags for each role will be configurable via synthesizer properties (similarly to how `externalId` is [exposed](#15604)) both for the `DefaultStackSynthesizer`, and for a custom synthesizer extending the `StackSynthesizer` class. The new properties will propagate down and will eventually be written to the cloud assembly. #### `+ manifest.json` ```json { "version": "36.0.0", "artifacts": { "MyStack.assets": { "type": "cdk:asset-manifest", "properties": { "file": "SeshTagsManifestStack.assets.json", "requiresBootstrapStackVersion": 6, "bootstrapStackVersionSsmParameter": "/cdk-bootstrap/hnb659fds/version" } }, "MyStack": { "type": "aws:cloudformation:stack", "environment": "aws://unknown-account/unknown-region", "properties": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-deploy-role-${AWS::AccountId}-${AWS::Region}", "assumeRoleAdditionalOptions": { "Tags": < deployRoleSessionTags > } "lookupRole": { "arn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-lookup-role-${AWS::AccountId}-${AWS::Region}", "requiresBootstrapStackVersion": 8, "bootstrapStackVersionSsmParameter": "/cdk-bootstrap/hnb659fds/version" "assumeRoleAdditionalOptions": { "Tags": < lookupRoleSessionTags > } } }, ``` #### `+ assets.json` ```json { "version": "36.0.0", "files": { "9ebfd704f02f99b2711998e6435822b0dbed6e80dcac7e75f339fe894861ac20": { "source": { "path": "mystack.template.json", "packaging": "file" }, "destinations": { "current_account-current_region": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-file-publishing-role-${AWS::AccountId}-${AWS::Region}" "assumeRoleAdditionalOptions": { "Tags": < fileAssetPublishingRoleSessionTags > } } } } }, "dockerImages": { "dockerHash": { "source": { "directory": "." }, "destinations": { "current_account-current_region": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-image-publishing-role-${AWS::AccountId}-${AWS::Region}" "assumeRoleAdditionalOptions": { "Tags": < imageAssetPublishingRoleSessionTags > } } } } } } ``` ### Description of how you validated changes - CLI integration tests. - CLI and framework unit tests. ### Checklist - [X] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
michelle-wangg
pushed a commit
to michelle-wangg/aws-cdk
that referenced
this pull request
Sep 23, 2024
Allow passing [all STS options](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters) to assume role configuration for various CDK roles. > The following PR description focuses on Session Tags because it was originally the only option we wanted to add support to. After some thought, we decided to allow all available STS options via a transparent pass-through. ### Prerequisites - cdklabs/cloud-assembly-schema#33 - cdklabs/cdk-assets#40 ### Issue # (if applicable) Closes aws#26157 Fixes aws#22535 ### Reason for this change Enabling [ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) via STS session tags. From the [AWS docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html): > _“Session Tags are key-value pair attributes that you pass when you assume an IAM role or federate a user in AWS STS. You do this by making an AWS CLI or AWS API request through AWS STS or through your identity provider (IdP). When you use AWS STS to request temporary security credentials, you generate a session. Sessions expire and have [credentials](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html), such as an access key pair and a session token. When you use the session credentials to make a subsequent request, the [request context](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html#AccessPolicyLanguage_RequestContext) includes the [aws:PrincipalTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) context key. You can use the aws:PrincipalTag key in the Condition element of your policies to allow or deny access based on those tags”_ ### Description of changes The CDK creates [4 IAM roles](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html#bootstrapping-env-roles) during bootstrap. It then assumes these roles at various phases of the deployment. - [DeploymentActionRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L429): Assumed when invoking CloudFormation operations such as _Deploy_ and _DescribeStackEvents_. - [FilePublishingRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L275): Assumed when file assets are uploaded to the bootstrap bucket. - [ImagePublishingRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L298): Assumed when docker images are published to the bootstrap ECR registry. - [LookupRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L321): Assumed while performing context lookups. Each of these roles should be assumable with their own specific session tags, as they server different purposes. > Note: The [CloudFormationExecutionRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L536) is also created during bootstrap, but the CLI never assumes it, therefore it doesn't need session tags support. Session tags for each role will be configurable via synthesizer properties (similarly to how `externalId` is [exposed](aws#15604)) both for the `DefaultStackSynthesizer`, and for a custom synthesizer extending the `StackSynthesizer` class. The new properties will propagate down and will eventually be written to the cloud assembly. #### `+ manifest.json` ```json { "version": "36.0.0", "artifacts": { "MyStack.assets": { "type": "cdk:asset-manifest", "properties": { "file": "SeshTagsManifestStack.assets.json", "requiresBootstrapStackVersion": 6, "bootstrapStackVersionSsmParameter": "/cdk-bootstrap/hnb659fds/version" } }, "MyStack": { "type": "aws:cloudformation:stack", "environment": "aws://unknown-account/unknown-region", "properties": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-deploy-role-${AWS::AccountId}-${AWS::Region}", "assumeRoleAdditionalOptions": { "Tags": < deployRoleSessionTags > } "lookupRole": { "arn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-lookup-role-${AWS::AccountId}-${AWS::Region}", "requiresBootstrapStackVersion": 8, "bootstrapStackVersionSsmParameter": "/cdk-bootstrap/hnb659fds/version" "assumeRoleAdditionalOptions": { "Tags": < lookupRoleSessionTags > } } }, ``` #### `+ assets.json` ```json { "version": "36.0.0", "files": { "9ebfd704f02f99b2711998e6435822b0dbed6e80dcac7e75f339fe894861ac20": { "source": { "path": "mystack.template.json", "packaging": "file" }, "destinations": { "current_account-current_region": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-file-publishing-role-${AWS::AccountId}-${AWS::Region}" "assumeRoleAdditionalOptions": { "Tags": < fileAssetPublishingRoleSessionTags > } } } } }, "dockerImages": { "dockerHash": { "source": { "directory": "." }, "destinations": { "current_account-current_region": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-image-publishing-role-${AWS::AccountId}-${AWS::Region}" "assumeRoleAdditionalOptions": { "Tags": < imageAssetPublishingRoleSessionTags > } } } } } } ``` ### Description of how you validated changes - CLI integration tests. - CLI and framework unit tests. ### Checklist - [X] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
HBobertz
pushed a commit
that referenced
this pull request
Sep 24, 2024
Allow passing [all STS options](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters) to assume role configuration for various CDK roles. > The following PR description focuses on Session Tags because it was originally the only option we wanted to add support to. After some thought, we decided to allow all available STS options via a transparent pass-through. ### Prerequisites - cdklabs/cloud-assembly-schema#33 - cdklabs/cdk-assets#40 ### Issue # (if applicable) Closes #26157 Fixes #22535 ### Reason for this change Enabling [ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) via STS session tags. From the [AWS docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html): > _“Session Tags are key-value pair attributes that you pass when you assume an IAM role or federate a user in AWS STS. You do this by making an AWS CLI or AWS API request through AWS STS or through your identity provider (IdP). When you use AWS STS to request temporary security credentials, you generate a session. Sessions expire and have [credentials](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html), such as an access key pair and a session token. When you use the session credentials to make a subsequent request, the [request context](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html#AccessPolicyLanguage_RequestContext) includes the [aws:PrincipalTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) context key. You can use the aws:PrincipalTag key in the Condition element of your policies to allow or deny access based on those tags”_ ### Description of changes The CDK creates [4 IAM roles](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html#bootstrapping-env-roles) during bootstrap. It then assumes these roles at various phases of the deployment. - [DeploymentActionRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L429): Assumed when invoking CloudFormation operations such as _Deploy_ and _DescribeStackEvents_. - [FilePublishingRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L275): Assumed when file assets are uploaded to the bootstrap bucket. - [ImagePublishingRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L298): Assumed when docker images are published to the bootstrap ECR registry. - [LookupRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L321): Assumed while performing context lookups. Each of these roles should be assumable with their own specific session tags, as they server different purposes. > Note: The [CloudFormationExecutionRole](https://github.com/aws/aws-cdk/blob/v2.154.1/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L536) is also created during bootstrap, but the CLI never assumes it, therefore it doesn't need session tags support. Session tags for each role will be configurable via synthesizer properties (similarly to how `externalId` is [exposed](#15604)) both for the `DefaultStackSynthesizer`, and for a custom synthesizer extending the `StackSynthesizer` class. The new properties will propagate down and will eventually be written to the cloud assembly. #### `+ manifest.json` ```json { "version": "36.0.0", "artifacts": { "MyStack.assets": { "type": "cdk:asset-manifest", "properties": { "file": "SeshTagsManifestStack.assets.json", "requiresBootstrapStackVersion": 6, "bootstrapStackVersionSsmParameter": "/cdk-bootstrap/hnb659fds/version" } }, "MyStack": { "type": "aws:cloudformation:stack", "environment": "aws://unknown-account/unknown-region", "properties": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-deploy-role-${AWS::AccountId}-${AWS::Region}", "assumeRoleAdditionalOptions": { "Tags": < deployRoleSessionTags > } "lookupRole": { "arn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-lookup-role-${AWS::AccountId}-${AWS::Region}", "requiresBootstrapStackVersion": 8, "bootstrapStackVersionSsmParameter": "/cdk-bootstrap/hnb659fds/version" "assumeRoleAdditionalOptions": { "Tags": < lookupRoleSessionTags > } } }, ``` #### `+ assets.json` ```json { "version": "36.0.0", "files": { "9ebfd704f02f99b2711998e6435822b0dbed6e80dcac7e75f339fe894861ac20": { "source": { "path": "mystack.template.json", "packaging": "file" }, "destinations": { "current_account-current_region": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-file-publishing-role-${AWS::AccountId}-${AWS::Region}" "assumeRoleAdditionalOptions": { "Tags": < fileAssetPublishingRoleSessionTags > } } } } }, "dockerImages": { "dockerHash": { "source": { "directory": "." }, "destinations": { "current_account-current_region": { "assumeRoleArn": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/cdk-hnb659fds-image-publishing-role-${AWS::AccountId}-${AWS::Region}" "assumeRoleAdditionalOptions": { "Tags": < imageAssetPublishingRoleSessionTags > } } } } } } ``` ### Description of how you validated changes - CLI integration tests. - CLI and framework unit tests. ### Checklist - [X] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
added the ability to specify an external id for the deploy-role as part of the synthesizer config.
this is similar to the existing functionality that allows specifying the external id for the image
and file publishing roles
In order to take advantage of this functionality you would need to customize the bootstrap template. To test this feature I customized the DeploymentActionRole in the bootstrap template to have the
AssumeRolePolicyDocumentas:I then created a test stack that specified that external id:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license