각 주 구성원 액세스 경계 정책은 무제한의 주 구성원 집합에 연결할 수 있으며 주 구성원 집합마다 주 구성원 액세스 경계 정책이 최대 10개까지 바인딩될 수 있습니다.
주 구성원 액세스 경계 정책을 주 구성원 집합에 연결하는 정책 바인딩 만들기
조직
다음 섹션에서는 각 정책 유형을 자세히 설명합니다.
주 구성원에게 액세스 권한을 부여하는 정책
주 구성원에게 리소스에 대한 액세스 권한을 부여하려면 IAM 허용 정책을 사용합니다.
허용 정책을 사용하면 Google Cloud의 리소스에 대한 액세스 권한을 부여할 수 있습니다. 허용 정책은 역할 바인딩과 메타데이터로 구성됩니다. 역할 바인딩은 리소스에 대한 특정 역할이 있어야 하는 주 구성원을 지정합니다.
허용 정책은 항상 단일 리소스에 연결됩니다. 허용 정책을 리소스에 연결하면 해당 리소스의 하위 요소에서 정책을 상속합니다.
허용 정책을 만들고 적용하려면 허용 정책을 수락하는 리소스를 식별한 후 해당 리소스의 setIamPolicy 메서드를 사용하여 허용 정책을 만듭니다. 허용 정책의 모든 주 구성원에게는 리소스와 리소스의 모든 하위 요소에 대한 지정된 역할이 부여됩니다. 각 리소스에 허용 정책 하나만 연결할 수 있습니다.
주 구성원의 리소스 액세스를 거부하려면 IAM 거부 정책을 사용합니다.
IAM 거부 정책은 IAM v2 API에서 사용 가능합니다.
허용 정책과 마찬가지로 거부 정책은 항상 단일 리소스에 연결됩니다.
프로젝트, 폴더 또는 조직에 거부 정책을 연결할 수 있습니다. 이 프로젝트, 폴더 또는 조직은 리소스 계층 구조에서 정책 상위 요소 역할도 합니다. 리소스에 거부 정책을 연결하면 해당 리소스의 하위 요소에서 정책을 상속합니다.
거부 정책을 만들고 적용하려면 IAM v2 API를 사용합니다 거부 정책을 만들 때 거부 정책이 연결될 리소스를 지정합니다. 거부 정책의 모든 주 구성원은 지정된 권한을 사용하여 해당 리소스 및 해당 리소스의 하위 요소에 액세스할 수 없습니다. 각 리소스에 거부 정책을 최대 500개까지 연결할 수 있습니다.
주 구성원이 액세스할 수 있는 리소스를 제한하려면 주 구성원 액세스 경계 정책을 사용합니다. 주 구성원 액세스 경계 정책은 IAM v3 API에서 사용 가능합니다.
주 구성원 액세스 경계 정책을 만들고 적용하려면 주 구성원 액세스 경계 정책을 만든 후 정책 바인딩을 만들어 해당 정책을 주 구성원 집합에 연결합니다.
주 구성원 액세스 경계 정책은 항상 조직의 하위 요소입니다.
주 구성원 액세스 경계 정책의 정책 바인딩은 정책 바인딩에서 참조된 주 구성원 집합에 가장 가까운 프로젝트, 폴더 또는 조직의 하위 요소입니다.
각 정책 바인딩은 주 구성원 액세스 경계 정책 하나를 주 구성원 집합 하나에 바인딩합니다. 주 구성원 액세스 경계 정책을 임의 개수의 주 구성원 집합에 바인딩할 수 있습니다. 각 주 구성원 집합에 주 구성원 액세스 경계 정책을 최대 10개까지 바인딩할 수 있습니다. 주 구성원 액세스 경계 정책을 삭제하면 해당 정책과 관련된 모든 정책 바인딩도 삭제됩니다.
주 구성원이 리소스에 액세스하려고 하면 IAM은 모든 관련 허용 정책, 거부 정책, 주 구성원 액세스 경계 정책을 평가하여 주 구성원이 리소스에 액세스할 수 있는지 확인합니다. 이러한 정책 중 하나라도 주 구성원이 리소스에 액세스할 수 없다고 표시되면 IAM에서 액세스를 차단합니다.
실제로 IAM은 모든 정책 유형을 동시에 평가한 후 결과를 컴파일하여 주 구성원이 리소스에 액세스할 수 있는지 확인합니다.
하지만 이 정책 평가는 다음 단계로 진행된다고 생각하면 도움이 됩니다.
IAM은 모든 관련 주 구성원 액세스 경계 정책을 검사하여 주 구성원이 리소스에 액세스할 수 있는지 확인합니다. 주 구성원 액세스 경계 정책은 다음이 참인 경우에 관련됩니다.
정책이 주 구성원이 포함된 주 구성원 집합에 바인딩되었습니다.
주 구성원 액세스 경계 정책이 주 구성원이 사용하려는 권한을 차단합니다. 주 구성원 액세스 경계 정책에서 차단하는 권한은 주 구성원 액세스 경계 정책 버전에 따라 다릅니다. 주 구성원 액세스 경계 정책을 만들 때 정책 버전을 지정합니다. 자세한 내용은 주 구성원 액세스 경계 정책 버전을 참조하세요.
관련 주 구성원 액세스 경계 정책을 확인하면 IAM에서 다음 중 하나를 실행합니다.
관련 주 구성원 액세스 경계 정책에 주 구성원이 액세스하려는 리소스가 없거나 IAM이 관련 주 구성원 액세스 경계 정책을 평가할 수 없으면 IAM에서 주 구성원의 리소스 액세스가 차단됩니다.
관련 주 구성원 액세스 경계 정책에 주 구성원이 액세스하려고 하는 리소스가 포함된 경우 IAM은 다음 단계로 진행합니다.
관련 주 구성원 액세스 경계 정책이 없으면 IAM이 다음 단계로 진행합니다.
IAM은 관련 거부 정책을 모두 검사하여 주 구성원이 권한을 거부했는지 확인합니다. 관련 거부 정책은 리소스에 연결된 거부 정책이자 상속된 거부 정책입니다.
이러한 거부 정책 중 하나라도 주 구성원이 필요한 권한을 사용하지 못하게 하면 IAM은 해당 리소스에 대한 액세스를 차단합니다.
거부 정책에서 주 구성원이 필요한 권한을 사용하지 못하게 하지 않으면 IAM은 다음 단계로 진행합니다.
IAM은 관련 허용 정책을 모두 검사하여 주 구성원에게 필요한 권한이 있는지 확인합니다. 관련 허용 정책은 리소스에 연결된 허용 정책이자 상속된 허용 정책입니다.
주 구성원에게 필요한 권한이 없으면 IAM은 주 구성원이 해당 리소스에 액세스하지 못하게 합니다.
[[["이해하기 쉬움","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 provides three types of policies: allow policies to grant access, deny policies to restrict access, and principal access boundary (PAB) policies to limit resource eligibility.\u003c/p\u003e\n"],["\u003cp\u003eAllow policies are attached to a single resource and grant principals specific roles, with each resource having only one allow policy.\u003c/p\u003e\n"],["\u003cp\u003eDeny policies, attached to a single resource, prevent principals from using specified permissions and allow for up to 500 deny policies per resource.\u003c/p\u003e\n"],["\u003cp\u003ePrincipal Access Boundary (PAB) policies restrict the resources a principal can access and can be bound to multiple principal sets, with each set allowing up to 10 PAB policies.\u003c/p\u003e\n"],["\u003cp\u003eIAM evaluates all relevant allow, deny, and PAB policies to determine if a principal can access a resource, starting with PAB policies, then deny policies, and finally allow policies.\u003c/p\u003e\n"]]],[],null,["# IAM policy types\n\nIdentity and Access Management (IAM) offers several types of policies to help you\ncontrol which resources principals can access. This page helps you\nunderstand the differences between how you use and manage these policy types.\n\nTypes of IAM policies in Google Cloud\n-------------------------------------\n\nIAM offers the following types of policies:\n\n- Allow policies\n- Deny policies\n- Principal access boundary (PAB) policies\n\nThe following table summarizes the differences between these policy types:\n\nThe following sections provide details about each policy type.\n\nPolicies to grant access to principals\n--------------------------------------\n\nTo grant principals access to resources, use IAM allow policies.\n\nAllow policies let you grant access to resources in Google Cloud. Allow\npolicies are made up of role bindings and metadata. Role bindings specify which\nprincipals should have a certain role on the resource.\n\nAllow policies are always attached to a single resource. After you attach an\nallow policy to a resource, the policy is [inherited](/iam/docs/resource-hierarchy-access-control) by that\nresource's descendants.\n\nTo create and apply an allow policy, you identify a resource that [accepts allow\npolicies](/iam/docs/resource-types-with-policies), then use that resource's\n`setIamPolicy` method to create the allow policy. All principals in the allow\npolicy are granted the specified roles on the resource and all of the resource's\ndescendants. Each resource can have only one allow policy attached to it.\n\nFor more information about allow policies, see [Understanding allow\npolicies](/iam/docs/allow-policies).\n\nPolicies to deny access to principals\n-------------------------------------\n\nTo deny principals access to resources, use IAM deny policies.\nIAM deny policies are available in the [IAM v2\nAPI](/iam/docs/reference/libraries#iam-v2).\n\nDeny policies, like allow policies, are always attached to a single resource.\nYou can attach a deny policy to a project, folder, or organization. This\nproject, folder, or organization also acts as the policy's parent in the\nresource hierarchy. After you attach a deny policy to a resource, the policy\nis [inherited](/iam/docs/deny-overview#inheritance) by that resource's descendants.\n\nTo create and apply deny policies, you use the IAM v2 API. When\nyou create a deny policy, you specify the resource that the deny policy is\nattached to. All principals in the deny policy are prevented from using the\nspecified permissions to access that resource and any of that resource's\ndescendants. Each resource can have up to\n500 deny policies attached to it.\n\nFor more information about deny policies, see [Deny policies](/iam/docs/deny-overview).\n\nPolicies to restrict the resources a principal can access\n---------------------------------------------------------\n\nTo restrict the resources that a principal is eligible to access, use a\nprincipal access boundary policy. Principal access boundary policies are available in the\n[IAM v3 API](/iam/docs/reference/rest/v3beta/organizations.locations.principalAccessBoundaryPolicies).\n\nTo create and apply a principal access boundary policy, you create a principal access boundary\npolicy, and then create a policy binding to connect that policy to a principal\nset.\n\nPrincipal access boundary policies are always children of your organization.\nPolicy bindings for principal access boundary policies are children of the project,\nfolder, or organization that is closest to the principal set referenced in the\npolicy binding.\n\nEach policy binding binds one principal access boundary policy to one principal set. A\nprincipal access boundary policy can be bound to any number of principal sets. Each\nprincipal set can have up to 10 principal access boundary\npolicies bound to it. When a principal access boundary policy is deleted, all of the\npolicy bindings related to that policy are also deleted.\n\nFor more information about principal access boundary policies, see [Principal access boundary\npolicies](/iam/docs/principal-access-boundary-policies).\n\nPolicy evaluation\n-----------------\n\nWhen a principal tries to access a resource, IAM evaluates all\nrelevant allow, deny, and principal access boundary policies to see if the principal is\nallowed to access the resource. If any of these policies indicates that the\nprincipal shouldn't be able to access the resource, then IAM\nprevents access.\n\nIn reality, IAM evaluates all policy types simultaneously, then\ncompiles the results to determine whether the principal can access the resource.\nHowever, it can be helpful to think of this policy evaluation taking place in\nthe following stages:\n\n1.\n IAM checks all relevant principal access boundary policies to see\n if the principal is eligible to access the resource. A principal access boundary\n policy is relevant if the following are true:\n\n - The policy is bound to a principal set that includes the principal\n - The principal access boundary policy blocks the permission that the principal is trying to use. The permissions that a principal access boundary policy blocks depends on the principal access boundary policy version. You specify the policy version when you create the principal access boundary policy. For more information, see [Principal access boundary\n policy versions](/iam/docs/principal-access-boundary-policies#versions).\n\n\n After checking the relevant principal access boundary policies,\n IAM does one of the following:\n - If the relevant principal access boundary policies don't include the resource that the principal is trying to access, or if IAM [can't\n evaluate](/iam/docs/principal-access-boundary-policies#fail-closed) the relevant principal access boundary policies, then IAM prevents them from accessing the resource.\n - If the relevant principal access boundary policies include the resource that the principal is trying to access, then IAM continues to the next step.\n - If there are no relevant principal access boundary policies, then IAM continues to the next step.\n2.\n IAM checks all relevant deny policies to see if the\n principal has been denied the permission. Relevant deny policies are the\n deny policies attached to the resource, as well as any [inherited deny policies](/iam/docs/deny-overview#inheritance).\n\n - If *any* of these deny policies prevent the principal from using a required permission, then IAM prevents them from accessing the resource.\n - If no deny policies prevent the principal from using a required permission, then IAM continues to the next step.\n3.\n IAM checks all relevant allow policies to see if the principal\n has the required permissions. Relevant allow policies are the allow\n policies attached to the resource, as well as any [inherited allow\n policies](/iam/docs/resource-hierarchy-access-control).\n\n - If the principal does not have the required permissions, then IAM prevents them from accessing the resource.\n - If the principal has the required permissions, then IAM lets them access the resource.\n\nThe following diagram shows this policy evaluation flow:\n\nWhat's next\n-----------\n\n- Learn more about [allow policies](/iam/docs/allow-policies).\n- Learn more about [deny policies](/iam/docs/deny-overview).\n- Learn more about [principal access boundary policies](/iam/docs/principal-access-boundary-policies)."]]
