This message was deleted.
# awss
sparse-intern-71089
12/29/2019, 2:59 PMThis message was deleted.
w
white-balloon-205
12/29/2019, 3:18 PM
What do you mean by “access” and what do you mean by “everything Pulumi creates”?
For access - do you mean read only or read-write? Many resources have several different kinds of access and many kinds of operations - do you expect just best guess subset of these?
For “everything” do you mean all the resources in one stack? All the resources in several stacks? Presumably just the AWS resources?
Also - curious - what will you use this user for?
f
flat-insurance-25294
12/29/2019, 3:20 PMSo we spin up entire infrastructure on feature branches.
Would be nice to create a user that only has access to the resources created on this branch (that means EKS, RDS, S3 etc)
The other issue was application access to AWS resources.
Our app needs to add/delete files in a specific S3 bucket and creates signed request cookies over Cloudfront.
So we would need a access_key/token generated when pulimi sets the infrastructure up to give to the apps/container.
Two separate things really, sorry for the confusion.
flat-insurance-25294
12/29/2019, 3:21 PMTo be fair I am having a really hard time understanding IAM.
But what I am trying to do is the ability to allow other devs access to the AWS account for the infrastructure they created in their pull request and nothing more.
o
orange-australia-91292
12/30/2019, 8:19 AMThat’s quite a bit of work. Not because it’s complicated or anything, but because there are a lot of permissions.
The way I go about it usually is try to simplify. For each resource type (ec2, s3, etc.) create a set of read/use/admin permissions. “read” means read-only, “use” means manipulate the resource in some way, “admin” means full access which usually involves being able to destroying the resource. What that means exactly for each AWS service differs a lot depending on service. For some it doesn’t make sense to have all three kinds, some might need a forth.
orange-australia-91292
12/30/2019, 8:20 AMThat gives me sets of actions that each permission can have on different services
orange-australia-91292
12/30/2019, 8:23 AMOnce these exist, comes the limit. How do you limit the permission to only the resources you want (ec2 instances, buckets, etc.). And that can usually be done in two ways. Assign tags to the resources you want and limit the permissions to only those tags. Where possible. And permission boundaries, that’s a new-ish thing.
orange-australia-91292
12/30/2019, 8:25 AMSo have a set of predefined permissions, then copy the one you need to the user and modify it to only apply to the tags you need. or boundaries, or whatever.
orange-australia-91292
12/30/2019, 8:25 AMThe basic idea is simple, but the amount of different permissions and combinations for each service makes it very annoying to set up.
orange-australia-91292
12/30/2019, 8:26 AMSome of these permission sets are already created by Amazon.
f
flat-insurance-25294
01/03/2020, 10:14 AMOk, in our case we spin up entire clusters.
A lot of rights have to be created.
Rights for our applications to write s3 buckets, create signed cookies on Cloudfront and sending emails on SES.
Rights for developers to access cluster and cloud watch logs.
Rights for our EKS cluster to start new nodes and etc.
Not really sure how to set all of that up.