Google Distributed Cloud（GDC）エアギャップの Identity and Access Management（IAM）を使用すると、どのリソースに誰がアクセスできるか、またそれらのリソースに対してどのようなアクションを実行できるかを制御できます。
GDC での IAM の仕組みを理解すると、アクセスを効果的に管理し、エアギャップ環境のセキュリティを維持しながら、メンバーがロールの実行に必要な権限を持つようにできます。
このドキュメントは、GDC エアギャップでの承認とアクセス制御について理解したいプラットフォーム管理者グループとアプリケーション オペレーター グループ（IT 管理者、セキュリティ エンジニア、アプリケーション デベロッパーなど）のユーザーを対象としています。また、インフラストラクチャ オペレーターがアクセス制御の概念の基礎を理解するのにも役立ちます。詳細については、 GDC エアギャップ ドキュメントの 対象読者をご覧ください。
アクセス制御モデル
GDC は、アクセスを 3 つのコア コンポーネント（誰（ メンバー）、何（ ロール）、どこ（ リソース スコープ））を中心に構成します。
アクセス制御は、自分が誰であるかを証明する（認証）と、何ができるかを判断する（承認）という 2 つの異なる段階で構成されます。
- 認証: GDC はユーザー アカウントやパスワードを保存しません。GDC は組織の ID プロバイダ（IdP）に接続するため、会社の認証情報でログインできます。
- 承認: 認証後、GDC IAM は割り当てられたロールを確認して、アクセスできるリソースと実行できるアクションを判断します。
メンバー
メンバーは、リソースへのアクセス権を付与できる ID です。 GDC は、メンバーを管理する場所に基づいて、人間の ID と人間以外の ID の 2 つのカテゴリに分類します。
人間の ID
人間の ID は、GDC にログインするユーザーとグループです。GDC は、ユーザー アカウントやパスワードを保存するのではなく、OpenID Connect（OIDC）や SAML 2.0 などの標準の ID 連携プロトコルを使用して、組織の既存のログイン システムまたは IdP（Active Directory、LDAP、Okta など）に接続します。
人間の ID には次の 2 種類があります。
- ユーザー: 会社の認証情報を使用してシステムにログインする個々のユーザー。
- グループ: 組織の IdP 内で管理されるユーザーのコレクション。グループにロールを付与すると、そのグループのすべてのメンバーに自動的に付与されます。
GDC は IdP を使用して人間の ID を一意に識別します。 環境は複数の IdP に接続できるため（部門ごとに異なるログイン システムを使用している場合など）、GDC は IdP を区別して、適切なユーザーにアクセス権を付与します。
アクセスを管理する場合、GDC はすべての外部ユーザー名とグループに一意の IdP 接頭辞を自動的に付加します。
- 形式:
idpprefix-username@domain.com（グループの場合はidpprefix-group-name）。 - 例: 組織の IdP が接頭辞
agency-aで構成されていて、alice@example.comとしてログインする場合、 GDC IAM はagency-a-alice@example.comとして認識します。
非人間 ID
人間以外の ID は、サービス ID（またはサービス アカウント）と呼ばれます。アプリケーション、スクリプト、自動化されたワークロードが API と安全にやり取りできるように、GDC 内で直接作成して管理します（ProjectServiceAccount リソースとして）。
サービス アカウントは GDC によって内部的に管理されるため、IdP 接頭辞は使用されません。代わりに、プロジェクトと名前で識別されます（gdcloud CLI を使用する場合は serviceAccount:projectName:serviceAccountName など）。
詳細については、 サービス アカウント キーを保護するをご覧ください。
権限とロール
権限とは、リソースに対して特定のアクション（VM の作成やデータベースの削除など）を実行する権限です。メンバーに権限を直接付与することはできません。代わりに、GDC は権限をロールにバンドルします。
GDC には次の 2 種類のロールがあります。
- 事前定義ロール: GDC によって作成、管理される権限の組み込みバンドル。GDC には、特定の職務やサービスに合わせて調整された事前定義ロールの包括的なライブラリが用意されています（プロジェクト閲覧者などの広範なロールから、バケット プロジェクト管理者や KMS 閲覧者などのきめ細かいサービスロールまで）。
- カスタムロール: 既存の事前定義ロールが組織のニーズを満たしていない場合に作成できる、ユーザー定義の権限バンドル。
IAM ロールを通じて付与される権限は純粋に付加的なものであり、アクセス権を付与しますが、拒否ルールは含まれません。メンバーに複数のロールを付与すると、そのメンバーはそれらのロールのすべての権限の和集合を受け取ります。組織全体の特定のサービスへのアクセスを制限または拒否するには、組織のポリシーを 設定します。
リソース スコープ
アクセス権は常に、GDC リソース階層の特定のレベルで付与します。スコープによって、メンバーがアクセスできるリソースが決まります。 マルチゾーン環境では、どちらのスコープで割り当てられたロールも、デフォルトですべてのゾーンに自動的に適用されます。
次のリソース スコープでロールを付与できます。
- 組織: 環境の最上位コンテナ。組織レベルで付与されたロールは組織全体に適用され、その中のすべてのプロジェクトとリソースに自動的に継承されます。
- プロジェクト: 特定のチームまたはアプリケーションのリソースをグループ化するために使用される、組織内のコンテナ。プロジェクトは厳格なセキュリティ境界として機能します。プロジェクト レベルで付与されたロールは、その特定のプロジェクトとそのリソース（仮想マシン、データベース、Kubernetes クラスタなど）にのみ適用されます。
詳細については、 リソース階層と マルチゾーン ユニバースの権限制御をご覧ください。
アクセスの承認方法
GDC は、主にロールベースのアクセス制御（RBAC）モデルを使用してアクセスを管理および承認します。RBAC モデルでは、個々のユーザーやワークロードに権限を直接割り当てません。代わりに、特定のリソース スコープでメンバーにロールを割り当てて、アクセスを決定します。
GDC は、次の Kubernetes カスタム リソースを使用して RBAC を実装します。
IAMRole: 特定の権限バンドルを定義します。IAMRoleBinding：組織またはプロジェクト スコープでメンバー（ユーザー、グループ、サービス アカウント） をIAMRoleにリンクします。
組織またはプロジェクトのリソースへのアクセス権を付与するには、GDC コンソール、gdcloud CLI を使用して IAMRoleBinding を作成するか、kubectl CLI を使用してカスタム リソース マニフェスト（YAML ファイル）を適用します。
たとえば、チームメンバーがプロジェクト内の仮想マシンを表示できるようにするには、そのプロジェクトのスコープで IAMRoleBinding を作成し、メンバーの ID を閲覧者ロールにリンクします。メンバーが仮想マシンを表示しようとすると、GDC はアクティブなロール バインディングを確認し、割り当てられたロールに必要な権限が含まれていることを確認して、リクエストを承認します。
GDC コンソールと gdcloud CLI はリソースに自動的に接続しますが、kubectl CLI を使用した直接 API アクセスでは、kubeconfig ファイルを生成して、そのリソースをホストする特定の Kubernetes クラスタまたは API サーバーに対する認証を行う必要があります。詳細については、 ログインして kubeconfig ファイルを生成するをご覧ください。
ロール バインディングの管理の詳細については、 アクセス権の付与と取り消しをご覧ください。
GDC エアギャップ IAM と の違い Google Cloud
でアクセスを管理したことがある場合 Google Cloud、 GDC は同様のコンセプトを使用しますが、 エアギャップの Kubernetes ベースのインフラストラクチャ内で動作するように実装が異なります。
次の表に、 GDC と Google Cloudの IAM の比較を示します。
| 機能 | 説明 | GDC エアギャップ | Google Cloud |
|---|---|---|---|
| ユーザー ID（認証） | ユーザーの認証に使用される ID システム。 |
必要な IdP 接頭辞（
たとえば、idpprefix-user@domain.com）を使用して、外部 IdP と連携します。
|
Google アカウント（Gmail など）または Cloud Identity または Google Workspace を介して連携された企業 ID。 |
| 承認エンジン | 権限を評価して適用する基盤となるシステム。 | 主に Kubernetes ロールベースのアクセス制御（RBAC）。アクセス リクエストは、ロール バインディングに対して API サーバーによってローカルで評価されます。組織のポリシーを使用して、リソースの制限を設定できます。 | Google のグローバル Cloud IAM サービス。リソース階層の任意のレベルで接続されたアクセス ポリシーに対して、API リクエストを 一元的に評価します。 |
| ロール バインディング | 特定のロールに対するメンバーのマッピング方法。 |
個々の IAMRoleBinding カスタム リソース。各バインディング
は、メンバーを 1 つのロールにリンクするオブジェクトです。IAM ロールの権限は純粋に付加的です（拒否ルールは組織のポリシーを通じて個別に構成できます）。 |
各リソース、 フォルダ、組織に接続された単一の IAM アクセス ポリシー。メンバーを ロールにマッピングする複数のバインディングが含まれており、条件付きルールまたは拒否ルールをサポートしています。 |
| サービス アカウント | アプリケーションと自動化されたワークロードで使用される人間以外の ID。 |
特定のプロジェクト内に作成されたローカル サービス アカウント
（ProjectServiceAccount）。公開鍵はクラスタに保存され、秘密鍵はクライアントによってローカルで管理および保護されます。
|
Google によって一元的に管理されるグローバル ID。認証情報は Google によって自動的に管理することも、キーファイルとしてダウンロードしてどこからでも認証することもできます。 |
| リソース階層 | リソースの整理と権限の継承に使用されるコンテナ構造。 | 2 階層: 組織 > プロジェクト | 多層階層: 組織 > フォルダ > プロジェクト |
| マルチゾーン権限スコープ | アベイラビリティ ゾーン またはリージョン間で権限を評価して伝播する方法。 | グローバル API サーバーによって管理される Kubernetes RBAC を使用します。これにより、ゾーン API サーバー間でロール バインディングが調整 およびレプリケートされるため、デフォルトですべてのゾーンにアクセスが適用されます。 すべてのゾーンにアクセスが適用されます。 | フルマネージドのグローバル IAM サービスを採用しています。任意のリソースレベルで割り当てられた権限は本質的にグローバルであり、すべてのリージョンとゾーンに自動的に適用されます。 |
| クライアント ツール | アクセスの管理に使用される主要なインターフェース、CLI ツール、API。 | GDC コンソール、gdcloud CLI、KRM API。 | Google Cloud コンソール、gcloud CLI、REST または gRPC API。 |
| 直接 API アクセス | ツールとスクリプトが API を使用してリソースを直接管理するために認証する方法。 | kubectl CLI を使用した直接 API アクセスでは、kubeconfig ファイルを生成して、そのリソースをホストする特定の Kubernetes クラスタまたは API サーバーに対する認証を行う必要があります。（GDC コンソールと gdcloud CLI はリソースに自動的に接続します）。 |
gcloud または REST/gRPC エンドポイントを使用した直接 API アクセスでは、クラスタ固有のログインを必要とせずに、すべてのサービスにグローバルに適用される一元化された認証情報（gcloud auth login）を使用します。 |
次のステップ
- 組織のログイン システムを接続するには、 ID プロバイダに接続するをご覧ください。
- 環境にログインするには、 ログインするをご覧ください。
- 権限を付与してロール バインディングを管理するには、 アクセス権の付与と取り消しをご覧ください。