Hello, I'm having a weird problem with

allowedAccountIds

and assuming a role in a different account. I'm using the TS version of aws-native. Previously I had an OIDC provider and a role for Pulumi in each account, so I never had to assume a role in a different account. That worked just fine. But, I wanted to make this a bit more manageable, so I set up a bastion/jump account with a role. Let's call the role

jump-role

. In each target account, I have a role with the privileges Pulumi needs and a trust relationship that allows

jump-role

to assume them. Let's call them

target-role

. The auth setup is not super complex: a CI job authenticates with the jump account using OIDC, and assumes

jump-role

. And I have the aws-native providers set up like this:

import * as aws from "@pulumi/aws-native"

const provider = new aws.Provider(
  "foo-provider",
  {
    region: "eu-central-1",
    allowedAccountIds: ["<target-account-id>"],
    assumeRole: {
      roleArn: "arn:aws:iam::<target-account-id>:role/target-role"
    },
    sharedCredentialsFile: "",
    skipCredentialsValidation: false,
    skipGetEc2Platforms: false,
    skipMetadataApiCheck: false,
    skipRegionValidation: false
  },
  {
    ignoreChanges: ["profile", "assumeRole"]
  }
)

// instantiate resources etc.

That is, the provider should pick up the OIDC credentials for

jump-role

from the environment, and them assume

target-role

using them. And that clearly happens, because I got an error message when I forgot to add assume role permissions to

jump-role

. However, after fixing the permissions, the instantiation of the first resource that uses the provider always fails with:

error: account ID not allowed (<bastion-account-id>)

Does the provider work as designed, or is there a bug here? I don't see a reason why the account id would be read with a session that has the original role (

jump-role

), instead of the role I told the provider to assume (

target-role

). I checked that the roles themselves are ok with AWS SDK. I was able to assume

target-role

using the CI's credentials, and STS GetCallerIdentity responded with

Account: "<target-account-id>"

, as expected.