IAM에서는 역할 부여 또는 권한 거부와 같은 액세스 변경사항이 eventual consistency를 갖습니다. 즉, 액세스 변경사항이 시스템 전체에 전파되려면 시간이 걸립니다. 그동안 최신 액세스 변경사항은 모든 곳에 적용되지 않을 수 있습니다. 예를 들어 주 구성원이 최근에 취소된 역할 또는 최근에 거부된 권한을 계속 사용할 수 있습니다. 또는 최근에 부여된 역할이나 최근까지 사용이 거부된 권한을 사용하지 못할 수도 있습니다.
조직의 허용 정책을 수정하여 주 구성원에게 조직 관리자 역할(roles/resourcemanager.organizationAdmin)을 부여합니다.
조직 수준 거부 정책을 수정하여 주 구성원의 cloudresourcemanager.googleapis.com/projects.setIamPolicy 권한을 거부합니다.
일반적으로 2분(7분 이상 걸릴 수 있음)
그룹 멤버십 변경
허용 또는 거부 정책에 포함된 Google 그룹에서 주 구성원을 추가하거나 삭제하여 액세스 권한을 변경합니다.
조직에 조직 관리자 역할이 부여된 org-admins@example.com 그룹이 있습니다. 그룹에 주 구성원을 추가하여 조직 관리자 역할을 부여합니다.
조직 수준에서 cloudresourcemanager.googleapis.com/projects.setIamPolicy 권한이 거부된 eng@example.com 그룹이 있습니다. 그룹에 주 구성원을 추가하여 cloudresourcemanager.googleapis.com/projects.setIamPolicy 권한을 거부합니다.
일반적으로 몇 분(몇 시간 이상 걸릴 수 있음)
중첩된 그룹의 멤버십 변경
상위 그룹이 허용 또는 거부 정책에 포함된 중첩된 그룹에서 주 구성원을 추가하거나 삭제하여 주 구성원의 액세스 권한을 변경합니다.
조직에 태그 뷰어 역할(roles/resourcemanager.tagViewer)이 부여된 admins@example.com 그룹이 있습니다. 이 그룹의 멤버십은 org-admins@example.com을 비롯한 다른 여러 그룹으로 구성되어 있습니다. org-admins@example.com 그룹에 주 구성원을 추가하여 태그 뷰어 역할을 부여합니다.
조직 수준에서 cloudresourcemanager.googleapis.com/projects.setIamPolicy 권한이 거부된 eng@example.com 그룹이 있습니다. 이 그룹의 멤버십은 eng-prod@example.com을 비롯한 다른 여러 그룹으로 구성됩니다. eng-prod@example.com 그룹에 주 구성원을 추가하여 cloudresourcemanager.googleapis.com/projects.setIamPolicy 권한을 거부합니다.
일반적으로 몇 분(몇 시간 이상 걸릴 수 있음)
또한 그룹 멤버십 변경 전파 방법은 다음 세부정보에 유의하세요.
일반적으로 그룹에 주 구성원을 추가하면 그룹에서 주 구성원을 삭제하는 것보다 빠르게 전파됩니다.
일반적으로 그룹 멤버십 변경사항은 중첩된 그룹 멤버십 변경보다 더 빠르게 전파됩니다.
이러한 전파 시간 추정값을 사용하여 주 구성원의 액세스 권한을 수정하는 방법을 알릴 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eIAM access changes, such as granting or denying permissions, are eventually consistent, meaning they don't take effect immediately across the entire system.\u003c/p\u003e\n"],["\u003cp\u003eThe time it takes for access changes to propagate varies depending on the method used, with policy changes typically taking around 2 minutes, potentially longer, and group membership changes taking several minutes to potentially hours.\u003c/p\u003e\n"],["\u003cp\u003eChanging a principal's access through group membership changes typically propagates faster than changes made via nested group memberships.\u003c/p\u003e\n"],["\u003cp\u003eAdding a principal to a group generally results in faster propagation of access changes than removing a principal from a group.\u003c/p\u003e\n"]]],[],null,["# Access change propagation\n\nIn IAM, access changes, such as granting a role or denying a\npermission, are [eventually consistent](https://wikipedia.org/wiki/Eventual_consistency). This means that it takes time for access changes to propagate\nthrough the system. In the meantime, recent access changes might not be effective\neverywhere. For example, principals might still be able to use a recently\nrevoked role or a recently denied permission. Alternatively, they might not be\nable to use a recently granted role or a permission they were, until recently,\ndenied from using.\n\nThe amount of time it takes for an access change to propagate depends on how you\nmake the access change:\n\nAlso keep in mind the following details for how group membership changes\npropagate:\n\n- In general, adding a principal to a group propagates faster than removing a principal from a group.\n- In general, group membership changes propagate faster than nested group membership changes.\n\nYou can use these propagation time estimates to inform the way you modify your\nprincipals' access."]]