ドメインで制限された共有を使用すると、ドメインまたは組織リソースに基づいてリソースの共有を制限できます。ドメインで制限された共有が有効な場合、許可されているドメインまたは組織に属するプリンシパルのみが、 Google Cloud 組織の IAM ロールの付与対象となります。
ドメイン別に共有を制限する方法
Organization Policy Service を使用して、ドメインまたは組織のリソースに基づいてリソースの共有を制限するには、次の方法があります。
iam.managed.allowedPolicyMembers
管理制約: この管理制約を適用すると、制約にリストされているプリンシパルとプリンシパル セットにのみロールを付与できます。このマネージド制約では、ロールの付与を許可するプリンシパルとプリンシパル セットを一覧表示します。組織内のすべてのプリンシパルにロールを付与できるようにするには、制約に組織のプリンシパル セットを含めます。
この制約の設定方法については、
iam.managed.allowedPolicyMembers
制約を使用してドメイン制限付き共有を実装するをご覧ください。iam.googleapis.com/AllowPolicy
リソースを参照するカスタム組織ポリシー: カスタム組織ポリシーを使用すると、特定のプリンシパルのセットにのみロールを付与できます。ほとんどの場合、カスタム組織のポリシーではなく、
iam.managed.allowedPolicyMembers
マネージド制約を使用する必要があります。ただし、次の構成オプションは、カスタム組織のポリシーを使用する場合にのみ使用できます。- メンバータイプに基づいて許可されたプリンシパルを構成する
- 特定のプリンシパルにロールが付与されないようにする
allUsers
やallAuthenticatedUsers
などの特別なプリンシパルにロールを付与できるようにする
カスタム組織のポリシーを使用してドメインで制限された共有を設定するには、次の CEL 関数を使用して、組織内でロールを付与できるユーザーを定義します。
組織内のすべてのプリンシパルにロールを付与できるようにするには、
memberInPrincipalSet
関数で組織のプリンシパル セットを指定し、制約に組織のプリンシパル セットを含めます。これらの CEL 関数を使用してカスタム組織のポリシーを作成する方法については、カスタム組織のポリシーを使用してドメイン制限付き共有を実装するをご覧ください。
iam.allowedPolicyMemberDomains
レガシー管理対象制約: このレガシー管理対象制約を適用すると、組織内のプリンシパルにのみロールを付与できるようになります。アクセスは、組織リソース ID または Google Workspace 顧客 ID に基づいて制限できます。これらの ID の違いについては、このページの組織リソース ID と Google Workspace のお客様 ID をご覧ください。この制約では、特定のプリンシパルの例外を構成できません。たとえば、
iam.allowedPolicyMemberDomains
制約を適用する組織のサービス エージェントにロールを付与する必要があるとします。サービス エージェントは Google によって作成および管理されるため、組織、Google Workspace アカウント、Cloud Identity ドメインの一部ではありません。そのため、サービス エージェントにロールを付与するには、制約を無効にしてロールを付与し、制約を再度有効にする必要があります。フォルダまたはプロジェクト レベルで組織のポリシーをオーバーライドして、どのユーザーがどのフォルダまたはプロジェクトでロールを付与できるかを変更できます。詳細については、プロジェクトの組織のポリシーをオーバーライドするをご覧ください。
この制約の設定方法については、
iam.allowedPolicyMemberDomains
制約を使用してドメイン制限付き共有を実装するをご覧ください。
ドメインで制限された共有の仕組み
組織のポリシーを使用してドメインで制限された共有を適用すると、指定したドメイン外のプリンシパルと個人には、組織内の IAM ロールを付与できません。
以降のセクションでは、組織でドメイン制限付き共有の制約がどのように機能するかについて、重要な詳細を説明します。
制約は遡及的ではない
組織のポリシーの制約は遡って適用されません。ドメイン制限が設定されると、この制限はその時点より後の許可ポリシーの変更に適用され、過去の変更には適用されません。
たとえば、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
)が削除されると、組織ポリシーにアクセスできなくなります。
Google グループとドメインで制限された共有
組織でドメイン制限の制約が適用されている場合、グループが許可されたドメインに属していても、新しく作成された Google グループにロールを付与できないことがあります。これは、グループが完全に反映されるまでに最大 24 時間かかることがあるためです。 Google Cloud新しく作成した Google グループにロールを付与できない場合は、24 時間待ってからもう一度お試しください。
また、グループが許可されたドメインに属しているかどうかを評価する場合、IAM はグループのドメインのみを評価します。グループのメンバーのドメインは評価されません。その結果、プロジェクト管理者は、外部メンバーを Google グループに追加し、それらの Google グループにロールを付与することで、ドメイン制限の制約を回避できます。
プロジェクト管理者がドメイン制限の制約を回避できないようにするために、Google Workspace 管理者は、グループ オーナーが Google Workspace 管理者パネルでドメイン外のメンバーを許可できないようにする必要があります。
組織リソース ID と Google Workspace お客様 ID
iam.allowedPolicyMemberDomains
レガシー マネージド制約を使用してドメインで制限された共有を実装する場合は、組織リソース ID または Google Workspace お客様 ID のいずれかに基づいてアクセスを制限できます。
組織リソース ID を使用すると、次のプリンシパルに組織内のロールを付与できます。
- 組織内のすべての Workforce Identity プール
- 組織内の任意のプロジェクト内のすべてのサービス アカウントと Workload Identity プール
- 組織内のリソースに関連付けられているすべてのサービス エージェント
Google Workspace お客様 ID を使用すると、次のプリンシパルに組織内のロールを付与できます。
- Google Workspace のお客様 ID に関連付けられているすべてのドメイン(サブドメインを含む)内のすべての ID
- 組織内のすべての Workforce Identity プール
- 組織内の任意のプロジェクト内のすべてのサービス アカウントと Workload Identity プール
- 組織内のリソースに関連付けられているすべてのサービス エージェント。
特定のサブドメインに対してドメイン制限付き共有を実装する場合は、サブドメインごとに個別の Google Workspace アカウントを作成する必要があります。複数の Google Workspace アカウントの管理について詳しくは、複数の組織の管理をご覧ください。