iam.allowedPolicyMemberDomains レガシー管理対象制約: このレガシー管理対象制約を適用すると、組織内のプリンシパルにのみロールを付与できるようになります。アクセスは、組織リソース ID または Google Workspace 顧客 ID に基づいて制限できます。これらの ID の違いについては、このページの組織リソース ID と Google Workspace のお客様 ID をご覧ください。
たとえば、examplepetstore.com と altostrat.com の 2 つの関連組織について考えてみましょう。examplepetstore.com ID に altostrat.com の IAM ロールが付与されている。その後、ドメインで ID を制限することに決め、altostrat.com にドメイン制限の制約を含む組織のポリシーを実装しました。この場合、既存の examplepetstore.com ID は altostrat.com でアクセス権を失いません。その時点から、altostrat.com ドメインの ID にのみ IAM ロールを付与できます。
制約は IAM ポリシーが設定されるたびに適用される
ドメイン制限の制約は、IAM ポリシーが設定されているすべてのアクションに適用されます。これには自動アクションも含まれます。たとえば、制約は、別の操作に応じてサービス エージェントが行う変更に適用されます。たとえば、BigQuery データセットをインポートする自動化サービスがある場合、BigQuery サービス エージェントは、新しく作成されたデータセットに対して IAM ポリシーの変更を行います。このアクションは、ドメインの制限によって制限され、ブロックされます。
制約にドメインが自動的に含まれない
ドメイン制限の制約を設定した場合、組織のドメインがポリシーの許可リストに自動的に追加されることはありません。ドメイン内のプリンシパルに組織内の IAM ロールを付与するには、ドメインを明示的に追加する必要があります。ドメインを追加せず、ドメイン内のすべてのユーザーから組織ポリシー管理者ロール（roles/orgpolicy.policyAdmin）が削除されると、組織ポリシーにアクセスできなくなります。
組織リソース ID と Google Workspace お客様 ID
iam.allowedPolicyMemberDomains レガシー マネージド制約を使用してドメインで制限された共有を実装する場合は、組織リソース ID または Google Workspace お客様 ID のいずれかに基づいてアクセスを制限できます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-18 UTC。"],[],[],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)."]]
