This message was deleted.

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.

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.

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.