This message was deleted.

I think this is something that a provider can help with, but I am struggling to find the documentation to confirm this

your stack should create a

parentProvider

and a

environmentProvider

. Naming is up to you. But your config should pass in whatever information is necessary to authenticate to the

parentProvider

and the

environmentProvider

. Your stacks will have different config to pass to the

environmentProvider

(because you will have a prod and a staging stack). Then you will just pass your

parentProvider

into any resource declarations that belong to the top-level account, and your

environmentProvider

to any resource declarations that belong to whichever child account that stack is configured to use

Hi Joshua, i'm not sure what you mean by "your stack should create a parentProvider". Do you mean that my stack will have one, or that I should configure one?

I mean this: https://www.pulumi.com/docs/reference/pkg/aws/provider/

Ok thanks, i'll give that a try now and let you know if i hit any other problems 🙂

shared

should be a different project, because it is deployed separately. Rember that "stacks" are different instances of the same resources

But there will be things in

staging

and / or

production

that will require access to

shared

resources

yes stacks can reference other stacks across projects, that is fine.

StackReference

can do that or you can provide it via config, whatever works for you

Okay

It needs to be a separate pulumi program

Is there perhaps a better way I could set this up that doesn't require separate projects? Is it possible for pulumi to share state across 2 stacks so it doesn't try to duplicate those resources?

the issue here isn't the sharing of state - that can be accomplished without any problem. The issue here is conceptually these are 2 different architectures and Pulumi's design is such that a project defines an architecture and a stack is an instance of that architecture. You have the first architecture which contains shared resources. This will be Pulumi Project 1 and it will declare your DNS resources, etc. It will have 1 stack because you only need 1 instance of these shared resources. Your second architecture is your application architecture. This will be Pulumi Project 2 and it will declare all of the resources for your application to run. You will have 2 stacks because you want 2 instances of this architecture (prod & staging). Part of this 2nd architecture is the fact that it refers to the single stack in Pulumi Project 1. All instances (stacks) of this architecture refer to that single stack in Pulumi Project 1.

Ah okay, I understand you now

cool, good luck! let me know if you need anymore help

How would the parentProvider work if the provider config is inside of a different project?

well both projects need access to the parent account, right? So you will need a provider that is authenticated to the parent account in both projects.

One thing i'm struggling with here is using the correct config for the environment. With

StackReference

i don't seem to be able to get secrets / config?

StackReference

is not meant to get config from another stack. Nor should you need to do that

How can I configure the parent provider if not with config?

You use the config for the project you are in

So the architecture project needs to have the config for the shared account stored in it too?

Does the architecture project need to create resources in the parent account? If so, yes.

ok

Alternatively, if you don't want Project 2 to be aware of what account the shared resources are in - than you should have Project 1's stack output the information you need to create your provider. Then you can

StackReference

and

.requireOutput()

that information

Looking at it now, i'm still not even sure if i'm doing the right thing here

At my company we use roles. So we have access keys that are configured in our environment, and we allow every provider we instantiate to just grab those same keys. But In order to tell the provider to place resources in a specific account we give it an

AssumeRoleArn

that has access to the desired account. So your IAM User has the permissions to assume the roles, and you tell the providers which role to assume which determines which account they act in

Is the role arn the account ARN?

Ours look like

arn:aws:iam::{accountNumber}:role/{roleName}

ohh i see, this is to do with IAM roles