Does Pulimi expose the arn of created r

Question

< white balloon 205> Does Pulimi expose the arn of created resources Like could I get `arn aws dynamodb us east 2 123456789012 table Books` somehow When creating a dynamodb for creating a Policy to give access to a group

broad-dog-22463 · Answer

You should be able to get the urn of that resource for use in policies

flat-insurance-25294 · Answer

How

broad-dog-22463 · Answer

Eg Const table = new aws dynamodb Table my table Export const tableArn = table arn This is just off my phone

broad-dog-22463 · Answer

Does this not work

flat-insurance-25294 · Answer

Oh there is `arn`properties on all the AWS resources

flat-insurance-25294 · Answer

Missed that thanks

flat-insurance-25294 · Answer

It s hard to scroll to the docs with so many static keys

broad-dog-22463 · Answer

There should be

flat-insurance-25294 · Answer

Thank you

broad-dog-22463 · Answer

Let me check for you

flat-insurance-25294 · Answer

Another question not really related to pulumi but more AWS Can I add more policies to a group in the future without replacing old ones Dev1 spins up their environment The policies for all resources are added to Dev1s group called DevGroup Dev2 spins up a new environment a bunch of resources are created These resources are added as policies to DevGroup

broad-dog-22463 · Answer

Yeah it s on the table

broad-dog-22463 · Answer

Yes in the second environment you would need to do a getGroup call to be able to manipulate the same group

flat-insurance-25294 · Answer

Well I assume just referencing the group with Pulumi wouldn t create a new one but reference it no

broad-dog-22463 · Answer

If you don t use a get request then it will try and create a new one

flat-insurance-25294 · Answer

Well I mean if it was created in Pulumi the first time would a second time have pulumi recreate it It seems counter productive to the whole declarative infrastructure

flat-insurance-25294 · Answer

I mean it uses Terraform underneath I d assume it would just refence the one previously created

broad-dog-22463 · Answer

If it s a different project with different state then it won t know it s managed by Pulumi

flat-insurance-25294 · Answer

Same project different stack

flat-insurance-25294 · Answer

We got Feature Staging Production stacks

broad-dog-22463 · Answer

So different state

broad-dog-22463 · Answer

So you need to run a get request to look it up

flat-insurance-25294 · Answer

That sucks but alright I guess I check if we re not in the prod stack we use a get otherwise regular pulumi AWS code

flat-insurance-25294 · Answer

Thank you for bringing that up

broad-dog-22463 · Answer

Stacks are like TF workspaces 100 isolated from each other

broad-dog-22463 · Answer

You can also use StackReference to pass the arn between the shared stacks for devs

flat-insurance-25294 · Answer

Right so if you export the group you can access it using stack references

broad-dog-22463 · Answer

Yessir

flat-insurance-25294 · Answer

Could you tell me if I am missing something here Deploying a feature branch creates all the resources needed and access a few shared resources New S3 Cloudfront EKS ECR access a few shared resources Groups Route53

flat-insurance-25294 · Answer

I would create those resources And add their access policy to the Groups

broad-dog-22463 · Answer

Seems correct

flat-insurance-25294 · Answer

That means new policy per branch While Staging dev and Production master Would share the ECR docker registry the dev branches would not each dev branch gets its unique ECR setup Production and Staging share ECR because Production will not build a new container it will just use the one Staging made So it needs access to the ECR there

broad-dog-22463 · Answer

In theory that seems correct but I don t know enough about your structure to know 100

flat-insurance-25294 · Answer

Fair enough appreciate the help I will experiment to figure things out Just mostly concerned about the whole Policy Attachment Role stuff that confuses the hell out of me

broad-dog-22463 · Answer

But adding access policies for each resource and adding to group sounds the correct order

broad-dog-22463 · Answer

Yeah Policies are painful

flat-insurance-25294 · Answer

Yeah especially when trying to limit them to resources created for that dev who pushed their branch

broad-dog-22463 · Answer

We Pulumi have stringly typed documents so it should be easy enough

flat-insurance-25294 · Answer

Yeah but managed policies the typed ones do not limit to specific resources right

flat-insurance-25294 · Answer

That s the confusion here Going through <https www pulumi com docs guides crosswalk aws iam >

flat-insurance-25294 · Answer

What s the difference between ```RolePolicyAttachment``` and ```PolicyDocument```

broad-dog-22463 · Answer

I d suggest if using TypeScript escalating an array and after each resource is created you can add the arn to the array and then loop over the array for it

flat-insurance-25294 · Answer

Yeah using TS

broad-dog-22463 · Answer

First one attaches a policy to a role the second one is for like sts assume role

broad-dog-22463 · Answer

They are different things

flat-insurance-25294 · Answer

I see We re avoiding the assume role stuff for now

broad-dog-22463 · Answer

That s an aws ism

flat-insurance-25294 · Answer

So I guess we want to use GroupPolicyAttachments

flat-insurance-25294 · Answer

or ```GroupPolicy```

broad-dog-22463 · Answer

I d suggest you model your policies in the aws console and see what they look like so you can make them in Pulumi

broad-dog-22463 · Answer

Otherwise you will have a lot of create destroy operations

flat-insurance-25294 · Answer

But what is the difference between GroupPoliyAttachment and just plain GroupPolicy because their TS Apis are different