https://pulumi.com
Join Slack
This message was deleted.
# getting-started
s
This message was deleted.
a
Like, for example, I want the dev stack to deploy to the dev aws account, and stg to the stg aws account.
s
No need to be embarrassed, everyone has to start somewhere! You should be able to accomplish this by creating an explicit AWS provider and then defining the properties for the provider. More information is available at https://www.pulumi.com/registry/packages/aws/api-docs/provider/
a
Awesome thank you Scott!
f
Also take a look at the 
aws:allowedAccountIds
config setting.
d
What we do is generally have a 
Pulumi.{stack}.yaml
per account and specify
Copy code
config:
  aws:allowedAccountIds: [xxx]
in that yaml file
✅ 1
We aren’t using a an explicit provider (right now) in the code itself (except in special circumstances), but we use explicit assumed roles to run 
pulumi up
via Pulumi Deployments
a
Are you passing arguments to pulumi up? Can you guys show me an example of over riding the provider?
d
So as far as I can tell, Pulumi acts on resources inside the account of the current role being used to create AWS resources. Via code you can explicitly create a provider: This is an example from our code that loops over all the accounts within an organization that has been setup via AWS Control Tower.
Copy code
# Create Provider to assume role
provider = aws.Provider(
    f"Provider: {account.name}",
    region="us-east-1",
    assume_role={
        "roleArn": pulumi.Output.format(
            "arn:aws:iam::{0}:role/AWSControlTowerExecution", account.id
        ),
    },
)
This creates a provider per account such that you can create resources in a specific account:
Copy code
aws.iam.AccountPasswordPolicy(
    name,
    **PASSWORD_PARAMS,
    opts=ResourceOptions(parent=self, provider=provider),
)
But for our “normal” stacks, which generally operate on a single account
a
Oh awesome thank you for this Aaron
d
We run 
pulumi up
with (e.g.) AWS_* credentials in the CLI environment for a specific account
(In reality we use https://github.com/benkehoe/aws-sso-util and https://awsu.me/ because we’re using SSO rather than IAM roles with access keys/secrets)
So something like (after initial setup)
Copy code
$ aws-sso-util login
# => browser opens and I approve

$ awsume MyAccount.AWSAdministratorAccess

$ pulumi up ...
And beyond that, we generally do not run 
pulumi up
against any of our non-sandbox infrastructure. We use #C048NVDH6DV to automatically run 
pulumi up
when PRs are merged
This may be TMI, but we have a “bootstrap” stack that creates an OIDC provider role for Pulumi Deployments to assume during runs that lives in our management account. Since this role is in our management account, this role itself has the ability to assume another role in any of the child accounts in our organization: in particular, the 
arn:aws:iam::{ACCOUNT_ID}:role/AWSControlTowerExecution
role. We then set up every stack with an explicit assume role configuration in the YAML:
Copy code
# project/Pulumi.yaml
name: my-project
runtime:
  name: python


# project/Pulumi.prod.yaml
config:
  aws:allowedAccountIds: [xxx]
  aws:assumeRole:
    roleArn: arn:aws:iam::xxx:role/AWSControlTowerExecution
  aws:region: us-east-1
👍 1
a
Is there a way I could just do this with the aws credentials file?
We don't have roles or SSO set up for these accounts yet..
nevermind I got it 🙂
👍🏽 1
3 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by