https://pulumi.com logo
Join Slack
Powered by
<@UB3BGTV63> Does Pulimi expose the arn of created...
# aws
f
@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?
b
You should be able to get the urn of that resource for use in policies
f
How?
b
Eg Const table = new aws.dynamodb.Table(“my-table”,{}): Export const tableArn = table.arn; This is just off my phone
Does this not work?
f
Oh there is `arn`properties on all the AWS resources?
Missed that - thanks!
It’s hard to scroll to the docs with so many static keys.
b
There should be
f
Thank you!
b
Let me check for you
f
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.
b
Yeah it’s on the table
Yes in the second environment you would need to do a getGroup call to be able to manipulate the same group
f
Well, I assume just referencing the group with Pulumi wouldn’t create a new one, but reference it- no?
b
If you don’t use a get request then it will try and create a new one
f
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.
I mean it uses Terraform underneath I’d assume it would just refence the one previously created.
b
If it’s a different project with different state then it won’t know it’s managed by Pulumi
f
Same project, different stack.
We got Feature/* Staging Production stacks.
b
So different state
So you need to run a get request to look it up
f
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.
Thank you for bringing that up.
b
Stacks are like TF workspaces - 100% isolated from each other
You can also use StackReference to pass the arn between the shared stacks for devs
f
Right, so if you export the group you can access it using stack references.
b
Yessir
f
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
I would create those resources. And add their access policy to the Groups
b
Seems correct
f
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.
b
In theory that seems correct but I don’t know enough about your structure to know 100%
f
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.
b
But adding access policies for each resource and adding to group sounds the correct order
Yeah Policies are painful :/
f
Yeah especially when trying to limit them to resources created for that dev who pushed their branch.
b
We (Pulumi) have stringly typed documents so it should be easy enough
f
Yeah but managed policies (the typed ones) do not limit to specific resources, right?
That’s the confusion here. Going through https://www.pulumi.com/docs/guides/crosswalk/aws/iam/
What’s the difference between
Copy code
RolePolicyAttachment
and
Copy code
PolicyDocument
b
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
f
Yeah using TS.
b
First one attaches a policy to a role the second one is for like sts assume role
They are different things
f
I see. We’re avoiding the assume_role stuff for now.
b
That’s an aws-ism
f
So I guess we want to use GroupPolicyAttachments.
or
Copy code
GroupPolicy
?
b
I’d suggest you model your policies in the aws console and see what they look like so you can make them in Pulumi
Otherwise you will have a lot of create / destroy operations
f
But what is the difference between GroupPoliyAttachment and just plain GroupPolicy because their TS Apis are different.
Open in Slack
PreviousNext
Powered by