# aws


01/17/2024, 2:05 PM
Hello, I'm having a weird problem with
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
. In each target account, I have a role with the privileges Pulumi needs and a trust relationship that allows
to assume them. Let's call them
. The auth setup is not super complex: a CI job authenticates with the jump account using OIDC, and assumes
. And I have the aws-native providers set up like this:
Copy code
import * as aws from "@pulumi/aws-native"

const provider = new aws.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
from the environment, and them assume
using them. And that clearly happens, because I got an error message when I forgot to add assume role permissions to
. However, after fixing the permissions, the instantiation of the first resource that uses the provider always fails with:
Copy code
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 (
), instead of the role I told the provider to assume (
). I checked that the roles themselves are ok with AWS SDK. I was able to assume
using the CI's credentials, and STS GetCallerIdentity responded with
Account: "<target-account-id>"
, as expected.
I looked into this some more. I allowed the jump account's id and enabled the refresh option of the preview command. It looks like CloudControl requests are done with
(and they target the jump account):
Copy code
error: Preview failed: operation error CloudControl: GetResource, https response error StatusCode: 400, RequestID: <snip>, api error AccessDeniedException: User: arn:aws:sts::<bastion-account-id>:assumed-role/jump-role/GitHubActions is not authorized to perform: cloudformation:GetResource on resource: arn:aws:cloudformation:eu-central-1:<bastion-account-id>:resource/* because no identity-based policy allows the cloudformation:GetResource action
Max verbosity + debug logs don't contain anything relevant.
I also tried setting
to the ARN of the correct role, but it had no effect even though CloudControl requests are supposed to use it. I'll probably create a bug report tomorrow because this doesn't make the least bit of sense to me 😄
> And that clearly happens, because I got an error message when I forgot to add assume role permissions to
. Actually, this came from some debugging code I forgot about. I looked into it, and I don't think Pulumi even tries to assume the role. I can work around this whole thing by assuming the roles externally and marshaling the credentials to the Pulumi programs (AWS SDK's standard env variables aren't enough because I need multiple providers with different credentials in one project). However, I'm going to submit a bug report anyway.