https://pulumi.com logo
Title
f

flat-insurance-25294

01/03/2020, 10:45 AM
@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

broad-dog-22463

01/03/2020, 10:46 AM
You should be able to get the urn of that resource for use in policies
f

flat-insurance-25294

01/03/2020, 10:46 AM
How?
b

broad-dog-22463

01/03/2020, 10:47 AM
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

flat-insurance-25294

01/03/2020, 10:48 AM
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

broad-dog-22463

01/03/2020, 10:48 AM
There should be
f

flat-insurance-25294

01/03/2020, 10:48 AM
Thank you!
b

broad-dog-22463

01/03/2020, 10:48 AM
Let me check for you
f

flat-insurance-25294

01/03/2020, 10:49 AM
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

broad-dog-22463

01/03/2020, 10:49 AM
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

flat-insurance-25294

01/03/2020, 10:52 AM
Well, I assume just referencing the group with Pulumi wouldn’t create a new one, but reference it- no?
b

broad-dog-22463

01/03/2020, 10:54 AM
If you don’t use a get request then it will try and create a new one
f

flat-insurance-25294

01/03/2020, 10:55 AM
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

broad-dog-22463

01/03/2020, 10:57 AM
If it’s a different project with different state then it won’t know it’s managed by Pulumi
f

flat-insurance-25294

01/03/2020, 10:58 AM
Same project, different stack.
We got Feature/* Staging Production stacks.
b

broad-dog-22463

01/03/2020, 10:58 AM
So different state
So you need to run a get request to look it up
f

flat-insurance-25294

01/03/2020, 10:58 AM
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

broad-dog-22463

01/03/2020, 10:59 AM
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

flat-insurance-25294

01/03/2020, 11:00 AM
Right, so if you export the group you can access it using stack references.
b

broad-dog-22463

01/03/2020, 11:01 AM
Yessir
f

flat-insurance-25294

01/03/2020, 11:02 AM
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

broad-dog-22463

01/03/2020, 11:02 AM
Seems correct
f

flat-insurance-25294

01/03/2020, 11:03 AM
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

broad-dog-22463

01/03/2020, 11:05 AM
In theory that seems correct but I don’t know enough about your structure to know 100%
f

flat-insurance-25294

01/03/2020, 11:05 AM
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

broad-dog-22463

01/03/2020, 11:05 AM
But adding access policies for each resource and adding to group sounds the correct order
Yeah Policies are painful :/
f

flat-insurance-25294

01/03/2020, 11:06 AM
Yeah especially when trying to limit them to resources created for that dev who pushed their branch.
b

broad-dog-22463

01/03/2020, 11:06 AM
We (Pulumi) have stringly typed documents so it should be easy enough
f

flat-insurance-25294

01/03/2020, 11:06 AM
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
RolePolicyAttachment
and
PolicyDocument
b

broad-dog-22463

01/03/2020, 11:07 AM
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

flat-insurance-25294

01/03/2020, 11:07 AM
Yeah using TS.
b

broad-dog-22463

01/03/2020, 11:07 AM
First one attaches a policy to a role the second one is for like sts assume role
They are different things
f

flat-insurance-25294

01/03/2020, 11:08 AM
I see. We’re avoiding the assume_role stuff for now.
b

broad-dog-22463

01/03/2020, 11:08 AM
That’s an aws-ism
f

flat-insurance-25294

01/03/2020, 11:08 AM
So I guess we want to use GroupPolicyAttachments.
or
GroupPolicy
?
b

broad-dog-22463

01/03/2020, 11:09 AM
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

flat-insurance-25294

01/03/2020, 11:16 AM
But what is the difference between GroupPoliyAttachment and just plain GroupPolicy because their TS Apis are different.