I guess what I really want is to create a user/tok...
# aws
I guess what I really want is to create a user/tokens with limited access to only everything pulimi creates.
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?
So 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.
To 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.
That’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.
That gives me sets of actions that each permission can have on different services
Once 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.
So 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.
The basic idea is simple, but the amount of different permissions and combinations for each service makes it very annoying to set up.
Some of these permission sets are already created by Amazon.
Ok, 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.