[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\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)."]]