In IAM, access changes, such as granting a role or denying a permission, are eventually consistent . This means that it takes time for access changes to propagate through the system. In the meantime, recent access changes might not be effective everywhere. For example, principals might still be able to use a recently revoked role or a recently denied permission. Alternatively, they might not be able to use a recently granted role or a permission they were, until recently, denied from using.
The amount of time it takes for an access change to propagate depends on how you make the access change:
Change a policy
Change a principal's access by editing an allow or deny policy.
When making policy changes, you can't exceed the limits on the number of principals allowed in a policy .
- You edit your organization's allow policy to grant a principal the
Organization Administrator role
(
roles/resourcemanager.organizationAdmin). - You edit an organization-level deny policy to deny a principal the
cloudresourcemanager.googleapis.com/permission.projects.setIamPolicy
Change a group's membership
Change a principal's access by adding or removing them from a Google group that's included in an allow or deny policy.
- You have a group,
org-admins@example.com, that is granted the Organization Administrator role on your organization. You add a principal to the group to give them the Organization Administrator role. - You have a group,
eng@example.com, that is denied thecloudresourcemanager.googleapis.com/permission at the organization level. You add a principal to the group to deny them theprojects.setIamPolicy cloudresourcemanager.googleapis.com/permission.projects.setIamPolicy
Change a nested group's membership
Change a principal's access by adding or removing them from a nested group whose parent group is included in an allow or deny policy.
- You have a group,
admins@example.com, that is granted the Tag Viewer role (roles/resourcemanager.tagViewer) on your organization. This group's membership is made up of a number of other groups, includingorg-admins@example.com. You add a principal to theorg-admins@example.comgroup to give them the Tag Viewer role. - You have a group,
eng@example.com, that is denied thecloudresourcemanager.googleapis.com/permission at the organization level. This group's membership is made up of a number of other groups, includingprojects.setIamPolicy eng-prod@example.com. You add a principal to theeng-prod@example.comgroup to deny them thecloudresourcemanager.googleapis.com/permission.projects.setIamPolicy
Also keep in mind the following details for how group membership changes propagate:
- In general, adding a principal to a group propagates faster than removing a principal from a group.
- In general, group membership changes propagate faster than nested group membership changes.
You can use these propagation time estimates to inform the way you modify your principals' access.
