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]

This file is a duplicate of https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md and should never have been committed.

[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.

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ CLI code has changed. A maintainer must run the code through the testing pipeline (git fetch origin pull/31089/head && git push -f origin FETCH_HEAD:test-main-pipeline), then add the 'pr-linter/cli-integ-tested' label when the pipeline succeeds.

PRs must pass status checks before we can provide a meaningful review.

If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing Exemption Request and/or Clarification Request.

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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