(cli): cdk diff cdk-assume-role-credential-plugin auth issue introduced in v1.75.0

I recently upgraded from v1.74.0 to v1.75.0, and our cdk diff started failing with the an auth error. We use the cdk-assume-role-credential-plugin to allow cdk to run via a user in our central authentication account.

Strangely, cdk deploy works fine, so this only affects cdk diff.

Reproduction Steps

We bootstrap our account using the CloudFormation template (https://raw.githubusercontent.com/aws/aws-cdk/master/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml) with the following params: “TrustedAccounts”: “our auth account id”, “Qualifier”: “infra”, “CloudFormationExecutionPolicies”: “arn:aws:iam::aws:policy/AdministratorAccess”

What did you expect to happen?

cdk diff should output differences between the stack definitions and the current deployed stacks.

What actually happened?

We get the following error message:

Could not assume role in target account (did you bootstrap the environment with the right '–trust’s?): User: arn:aws:sts::676932xxxxxx:assumed-role/cdk-infra-deploy-role-676932xxxxxx-us-east-1/676932xxxxxx-0-session is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::676932xxxxxx:role/cdk-infra-deploy-role-676932xxxxxx-us-east-1

Environment

• CDK CLI Version : 1.75.0
• Framework Version: ?
• Node.js Version: v15.3.0
• OS : Debian Buster
• Language (Version): OpenJDK Runtime Environment (build 11.0.9+11-post-Debian-1deb10u1)

We run our CDK in the following docker container, if that helps at all:

https://hub.docker.com/repository/docker/strategicblue/cdk

FROM node:buster

ENV MVN_VERSION 3.6.3

RUN npm install -g aws-cdk cdk-assume-role-credential-plugin \
  && apt-get update \
  && apt-get install -y openjdk-11-jdk \
  && curl -fsSLO --compressed "https://downloads.apache.org/maven/maven-3/$MVN_VERSION/binaries/apache-maven-$MVN_VERSION-bin.tar.gz" \
  && tar -xzf "apache-maven-$MVN_VERSION-bin.tar.gz" -C /usr/local --strip-components=1 --no-same-owner \
  && rm "apache-maven-$MVN_VERSION-bin.tar.gz"

Other

The failure message is weird, because it suggests that cdk has already assumed the correct role in the target account, but is then trying to assume the role again, and that role doesn’t have sts permissions to assume itself, so that fails.

---

This is 🐛 Bug Report

[jmortlock]

I think the logic for the case where no credential providers are provided is also to strict as the current credential check explicitly matches the account you are deploying / diffing into

(if you didn't have any credential plugins configured)
    [cli] No credential providers, I'm going to use AWS CLI credentials.
    if) Check if the destination account matches the current credentials account (obtainCredentials method)
        [cli] Okay let me use those to assume into `cdk-hnb659fds-deploy-role-11111111111-us-east-1`
      (it works)
   else)
      [cli] error Need to perform AWS calls for account xxxx, but the current credentials are for yyyy

Also look forward to moving forward without the cdk-assume-role-credential-plugin plugin 😃

[polothy]

Just wanted to chime in and +1 this comment: https://github.com/aws/aws-cdk/issues/11792#issuecomment-740231089

This is the only reason why I use the cdk-assume-role-credential-plugin. Without the plugin, I get this error:

Need to perform AWS calls for account AAA, but the current credentials are for BBB.

I configure the plugin to just use the bootstrap role in cdk.json:

"assume-role-credentials:readIamRoleName": "cdk-hnb659fds-deploy-role-{ACCOUNT_ID}-us-east-1"

And this basically allowed me to get past the Need to perform AWS calls... error and then CDK would go ahead and assume the new bootstrap roles for me. This is incredibly useful for deploying a stack that depend on other stacks that are not in the same account. A single cdk deploy root-stack-name deploys all the stacks to all the different AWS accounts. Otherwise, I’d have to deploy them separately, passing in different credentials, which aren’t even used due to the switching to the new bootstrap roles.

I did also try the new --lookups=false flag, in hopes it would skip this AWS account check, but get the same error.

Any recommendations on how to get CDK to just attempt to assume the new bootstrap roles vs doing the account ID checking? Right now, it only seems possible with this plugin.