#8142 source of truth for AWS IAM permissions
Closed: Fixed 9 days ago by kevin. Opened 3 months ago by dustymabe.

We are in a state where we need more permissions for AWS in order to replicate images across regions. It would be best for us if we can collaborate on the permissions granted and also test them out in our community testing account before we make requests to the infra team to grant the permissions.

Can we write them down somewhere and have that source (json files) be the source of truth for our AWS IAM policies?

Right now we think we need ec2:DescribeImageAttribute permissions but who knows what else we'll need after that. If we can replicate the exact permission set then we can be a little more methodical about testing and requesting additional permissions.


I'm trying to deal with this right now in fact. :(

We have N groups wanting to use our one aws account and I really really don't want all of them to have access to everything. I'm working on trying to get something working with resource tagging that would allow each group to have pretty wide privs, but only on things tagged with their own project. Unfortunately, it's not proving easy (although you would think people have done this many times before). ;(

Once I get something working I can put it in the ansible repo or infra docs or something.

Metadata Update from @kevin:
- Issue assigned to kevin
- Issue priority set to: Waiting on Assignee (was: Needs Review)

3 months ago

I'm working on trying to get something working with resource tagging that would allow each group to have pretty wide privs, but only on things tagged with their own project.

resource tagging sure does sound interesting. I wouldn't mind setting this up in the community test account once you get it figured out.

Once I get something working I can put it in the ansible repo or infra docs or something.

Putting it in the ansible repo and even having the perms be able to be applied/deleted that way would be super optimal.

Thanks @kevin

but only on things tagged with their own project.

I've encountered this problem a few times with "cloud" accounts. We only have one account but we want to essentially namespace different projects. I feel like the project/namespace concept in kubernetes/openshift is so useful I wish AWS had something similar.

hey @kevin - did we ever get this sorted out? this is currently blocking uploading Fedora CoreOS to other AWS regions.

I did not. We can schedule some time later today to work through what perms you need and grant them. :)

Scheduled for 2pm PDT later today.

Metadata Update from @kevin:
- Issue tagged with: backlog

2 months ago

I did not. We can schedule some time later today to work through what perms you need and grant them. :)

Finally got it worked out exactly what we need for now. We need this applied to the fcos-upload-amis policy:

$ git diff
diff --git a/notes/aws-iam-policies/prod-account/fcos-upload-amis b/notes/aws-iam-policies/prod-account/fcos-upload-amis
index e49909d..2a82fa4 100644
--- a/notes/aws-iam-policies/prod-account/fcos-upload-amis
+++ b/notes/aws-iam-policies/prod-account/fcos-upload-amis
@@ -12,6 +12,7 @@
                 "ec2:ImportSnapshot",
                 "ec2:CopyImage",
                 "ec2:ModifyImageAttribute",
+                "ec2:DescribeImageAttribute",
                 "ec2:DescribeSnapshots",
                 "ec2:DescribeImportSnapshotTasks",
                 "ec2:DescribeImages",

Done. Can you check and see if you can do what you need now?

Done. Can you check and see if you can do what you need now?

yes we are unblocked for now. Leaving this ticket open still for the longer term solution.

I have checked in copies of our policies to ansible in files/aws/iam/policy/

Please feel free to send patches/adjust them. :)

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

9 days ago

Login to comment on this ticket.

Metadata