Vicious circle with giving a role permission to edit iam policies

Hey all,

I am running into a vicious circle issue: I am creating a policy to attach to a role (lets say the devops role) which allows that role to update a resource (lets say a kms key). All easy and hunky-dory.

Now this new policy that I just created is owned by me, but i want to grant the same devops role permission to update that policy, so the devops role can change that policy if needed (add or remove an action maybe, or include another resource). This is easy. I just make another policy to give the devops role permission to edit the previou…, hang on…

I assume the problem is becoming clear. I am creating new policies to allow the devops role to update previously created policies. But somewhere there is going to be a policy that the devops role can’t edit…

The only real solution I see is to give the role running terraform permission to edit any policy (use a wildcard as resource). But that doesn’t seem to follow the least privileges principle. I think i am missing something in my knowledge on how this is normally solved. Is there a way to make a policy that gives a role permission to edit that same policy, plus edit other policies? Like a self reference arn that refers to the policy itself?
Any pointers are appreciated.

1 Like

You’re running into a classic IAM bootstrapping issue. The key is IAM policy self-management with a carefully scoped policy. Instead of using wildcards, try:

  1. Attach a permissions boundary to the DevOps role, defining what it can and cannot modify.
  2. Use a condition in the policy to allow editing only policies with a specific tag or naming convention.
  3. Explicitly grant permission for the DevOps role to modify only the policies it owns, using "aws:ResourceTag" conditions.

This way, you maintain control while avoiding excessive privileges.