User attributes / PrincipalTag propagation time

Question

Tl;dr: How long does it take for IAM Identity Management user attribute changes to propagate?

Hi there!

I set up a policy so that users, whose Division attribute matches a Tag "Division" on an instance, shall be able to start/stop it. This is working, but I noticed that my test user still can manage the instance even after I changed the Division attribute, and the policy condition should fail. Does anyone know why there is a delay, how long that can be, and what I can do to get the "real" value, not what it has been before?

I am asking because all the docs I found said that such changes were more or less instantaneous. But I have spent quite some time on this, debugging, trying to figure out why my test policy did not work, talking to ChatGPT for hours and trying all the suggestions (some rather good ones actually), wondering what kind of stupid mistake I am doing all the time. I learnt about the IAM Policy Simulator that way, and there it *was* working. So why not in real life?

A problem with the policy simulator is that I cannot pick my test user as that comes from IAM Identity Management, not IAM - the test user shows up as assumed-role/AWSReservedSSO_DevTeamMemberAccess_xxx/testuser", but not in the policy simulator. There I can only select the AWSReservedSSO_DevTeamMemberAccess_xxx role, but that itself does not have a Division. However, the simulator detects that I am comparing "aws:PrincipalTag/Division" and offers to fill the values. When I fill the values as the test user has them set, all is working. And also in reality, unless I change the Dision. Then it takes a while. Even signing out and in again does not seem to help here reliably.

Best regards,
Alex

FYI, this is the policy:
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AlexTestPolicy",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "aws:PrincipalTag/Division": "*${ec2:ResourceTag/Division}*"
                }
            }
        }
    ]
}
```

Answer

Hi,
The policy you used gives users with the same division type access to start the instances. this however doesn't imply that only they can do the actions. Therefore, assuming your user still has ec2:StartInstances or ec2:* to resources:*, you won't be revoked of that access.

Since it is evident that you are using AWS Organizations, I recommend using Custom Service Control Policies instead.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Answer

Hi Gab, thanks for your reply!

I had used a test account that had no other permissions. The account was unable to start/stop instances first, and it worked after the Division had been set accordingly. But it keeped working after I changed the Division back, for quite some time, until eventually it stopped. Weird, but in the end, no big problem.

Whoops, and after a month I come back and find this draft stil unsent - sorry. Yeah, I had opened a browser tab to check out the Service control policies stuff, and never got around to it, until now. Interesting stuff, actually! Another layer of control, that's cool. Not sure yet how to apply it in my case. They deny access to ressources, but if I set such a rule via SCP that denies if the Division does not match, ow would I make exceptions? But that's getting outside of this questions's scope I guess, I'll just keep on reading on that stuff.

User attributes / PrincipalTag propagation time

Relevanter Inhalt