旧版受管理限制条件 iam.allowedPolicyMemberDomains：您可以强制执行此旧版受管理限制条件，以仅允许向组织中的主账号授予角色。您可以根据组织资源 ID 或 Google Workspace 客户 ID 限制访问权限。如需了解这些标识符之间的区别，请参阅本页上的组织资源 ID 与 Google Workspace 客户 ID。
此限制不允许您为特定正文配置例外情况。例如，假设您需要在实施 iam.allowedPolicyMemberDomains 限制条件的组织中向服务代理授予角色。服务代理由 Google 创建和管理，因此不属于您的组织、Google Workspace 账号或 Cloud Identity 网域。因此，如需向服务代理授予角色，您需要停用该限制，授予角色，然后重新启用该限制。
[[["易于理解","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-08-18。"],[],[],null,["# Domain restricted sharing lets you limit resource sharing based on a domain or\norganization resource. When domain restricted sharing is active, only principals\nthat belong to allowed domains or organizations can be granted\nIAM roles in your Google Cloud organization.\n\nMethods for restricting sharing by domain\n-----------------------------------------\n\nThere are several ways that you can use Organization Policy Service to limit resource\nsharing based on domain or organization resource:\n\n- **The `iam.managed.allowedPolicyMembers` managed constraint**: You can\n enforce this managed constraint to allow roles to be granted to only the\n principals and principal sets that you list in the constraint.\n\n With this managed constraint, you list the principals and principal sets\n that you want to allow roles to be granted to. To allow roles to be granted\n to all principals in your organization, include the organization's principal\n set in the constraint.\n\n To learn how to set this constraint, see [Use the\n `iam.managed.allowedPolicyMembers` constraint to implement domain restricted\n sharing](/resource-manager/docs/organization-policy/restricting-domains#managed-constraint).\n- **A custom organization policy referencing the\n `iam.googleapis.com/AllowPolicy` resource**: You can use a custom organization\n policy to allow roles to be granted to only a specific set of principals.\n\n In most cases, you should use the `iam.managed.allowedPolicyMembers` managed\n constraint instead of using a custom organization policy. However, the\n following configuration options are only available if you use custom\n organization policies:\n - Configuring allowed principals based on member type\n - Preventing specific principals from being granted roles\n - Allowing roles to be granted to special principals like `allUsers` and `allAuthenticatedUsers`\n\n To set up domain restricted sharing with custom organization policies, you\n use the following CEL functions to define who can be granted a role in your\n organization:\n - [`memberInPrincipalSet`](/iam/docs/org-policy-custom-constraints#member-in-principal-set)\n - [`memberTypeMatches`](/iam/docs/org-policy-custom-constraints#member-type-matches)\n - [`memberSubjectMatches`](/iam/docs/org-policy-custom-constraints#member-subject-matches)\n\n To allow roles to be granted to all principals in your organization, specify\n your organization's principal set in the `memberInPrincipalSet` function\n include the organization's principal set in the constraint.\n\n To learn more about how to create custom organization policies using these\n CEL functions, see [Use custom organization policies to implement domain\n restricted sharing](/resource-manager/docs/organization-policy/restricting-domains#custom-constraint).\n- **The `iam.allowedPolicyMemberDomains` legacy managed constraint** : You can\n enforce this legacy managed constraint to only allow roles to be granted to\n principals in your organization. You can limit access based on your\n organization resource ID or your Google Workspace customer ID. To see\n differences between these identifiers, see [Organization resource ID versus\n Google Workspace customer ID](#org-id-vs-customer-id) on this page.\n\n This constraint doesn't let you configure exceptions for specific\n principals. For example, imagine that you need to grant a role to a [service\n agent](/iam/docs/service-account-types#service-agents) in an organization that enforces the\n `iam.allowedPolicyMemberDomains` constraint. Service agents are created and\n managed by Google, so they aren't part of your organization, your\n Google Workspace account, or your Cloud Identity domain. As a result, to\n grant a role to the service agent, you need to disable the constraint,\n grant the role, and then re-enable the constraint.\n\n You can override the organization policy at the folder or project level to\n change which users are allowed to be granted roles in which folders or\n projects. For more information, see [Override the organization policy for a\n project](/resource-manager/docs/organization-policy/using-constraints#override_the_organization_policy_for_a_project).\n\n To learn how to set this constraint, see [Use the\n `iam.allowedPolicyMemberDomains` constraint to implement domain restricted\n sharing](/resource-manager/docs/organization-policy/restricting-domains#predefined-constraint).\n\n\n | **Note** : If your organization was created on or after May 3, 2024, then the `iam.allowedPolicyMemberDomains` predefined constraint is enforced by default, with your domain listed as the only allowed value.\n\n \u003cbr /\u003e\n\nHow domain restricted sharing works\n-----------------------------------\n\nWhen you use an organization policy to enforce domain restricted sharing,\nno principals outside of the domains and individuals that you specify can be\ngranted IAM roles in your organization.\n\nThe following sections outline some key details about how domain restricted\nsharing constraints work in your organization.\n\n### Constraints are not retroactive\n\nOrganization policy constraints are not retroactive. After a domain restriction\nis set, the limitation applies to allow policy changes made from that point\nforward, and not to any previous changes.\n\nFor example, consider two related organizations: `examplepetstore.com` and\n`altostrat.com`. You have granted an `examplepetstore.com` identity\nan IAM role in `altostrat.com`. Later, you decided to restrict\nidentities by domain, and implemented an organization policy with the domain\nrestriction constraint in `altostrat.com`. In this case, the existing\n`examplepetstore.com` identities wouldn't lose access in altostrat.com. From\nthat point, you could only grant IAM roles to identities from\nthe altostrat.com domain.\n\n### Constraints apply whenever an IAM policy is set\n\nDomain restriction constraints apply to all actions where an IAM\npolicy is set. This includes automated actions. For example, the constraints\napply to changes that a [service agent](/iam/docs/service-account-types#service-agents) makes in\nresponse to another action. For example, if you have an automated service that\nimports BigQuery datasets, a BigQuery service agent will make\nIAM policy changes on the newly created dataset. This action\nwould be restricted by the domain restriction constraint and blocked.\n\n### Constraints don't automatically include your domain\n\nYour organization's domain isn't automatically added to the allowed list of a\npolicy when you set the domain restriction constraint. To let principals in your\ndomain be granted IAM roles in your organization, you must add\nyour domain explicitly. If you don't add your domain and the Organization Policy\nAdministrator role (`roles/orgpolicy.policyAdmin`) is removed from all users in\nyour domain, then the organization policy becomes inaccessible.\n\n### Google groups and domain restricted sharing\n\nIf the domain restriction constraint is enforced in your organization, then you\nmight not be able to grant roles to newly created Google groups, even if the\ngroups belong to an allowed domain. This is because it can take up to 24 hours\nfor a group to fully propagate through Google Cloud. If you can't grant a\nrole to a newly created Google group, wait 24 hours and then try again.\n\nAdditionally, when evaluating whether a group belongs to an allowed domain,\nIAM only evaluates the group's domain. It doesn't evaluate the\ndomains of any of the group's members. As a result, project administrators can\nbypass the domain restriction constraint by adding outside members to Google\ngroups, and then granting roles to those Google groups.\n\nTo ensure that project administrators can't bypass the domain restriction\nconstraint, the Google Workspace administrator should ensure that group owners\ncannot [allow members from outside of the\ndomain](https://support.google.com/a/answer/167097) in the\nGoogle Workspace administrator panel.\n\nOrganization resource ID versus Google Workspace customer ID\n------------------------------------------------------------\n\nIf you use the `iam.allowedPolicyMemberDomains` legacy managed constraint to\nimplement domain restricted sharing, then you can limit access based on either\nyour organization resource ID or your Google Workspace customer ID.\n\nUsing your organization resource ID allows the following principals to\nbe granted roles in your organization:\n\n- All workforce identity pools in your organization\n- All service accounts and workload identity pools in any project in the organization\n- All [service agents](/iam/docs/service-account-types#service-agents) associated with resources in your organization\n\nUsing your Google Workspace customer ID allows the following\nprincipals to be granted roles in your organization:\n\n- All identities in all domains, including subdomains, associated with your Google Workspace customer ID\n- All workforce identity pools in your organization\n- All service accounts and workload identity pools in any project in the organization\n- All [service agents](/iam/docs/service-account-types#service-agents) associated with resources in your organization.\n\nIf you want to implement domain restricted sharing for specific subdomains, then\nyou need to create a separate Google Workspace account for each subdomain. For\nmore information about managing multiple Google Workspace accounts, see\n[Managing multiple\norganizations](/resource-manager/docs/managing-multiple-orgs)."]]
