feat: allow all sts options for roles assumed by the cli

[sumupitchayan]

Allow passing all STS options 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

• feat: additional options when assuming roles cdklabs/cloud-assembly-schema#33
• feat: additional options when assuming publishing roles cdklabs/cdk-assets#40

Issue # (if applicable)

Closes #26157
Fixes #22535

Reason for this change

Enabling ABAC via STS session tags. From the AWS docs:

“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, such as an access key pair and a session token. When you use the session credentials to make a subsequent request, the request context includes the aws: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 during bootstrap. It then assumes these roles at various phases of the deployment.

• DeploymentActionRole: Assumed when invoking CloudFormation operations such as Deploy and DescribeStackEvents.
• FilePublishingRole: Assumed when file assets are uploaded to the bootstrap bucket.
• ImagePublishingRole: Assumed when docker images are published to the bootstrap ECR registry.
• LookupRole: 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 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) 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

{
  "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

{
  "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

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[iliapolo]

@rix0rrr Can you have a look at this (and how its being used)? I added it since your last review to fix the lookup issues.

stale

[iliapolo]

This file is a copy of https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md and is actually configured to be ignored:

aws-cdk/packages/@aws-cdk/cx-api/.gitignore

Lines 3 to 9 in 1593500

	*
	!package.json
	!.npmignore
	!jest.config.js
	!LICENSE
	!NOTICE
	!CONTRIBUTING.md

But since it was committed before the ignore rules were put in place, it still lingers on.

[aws-cdk-automation]

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 0c753cf
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.