Google Distributed Cloud（GDC）エアギャップ アプライアンスの Identity and Access Management（IAM）を使用すると、どのリソースに誰がアクセスできるか、またそれらのリソースに対してどのようなアクションを実行できるかを制御できます。
GDC での IAM の仕組みを理解すると、アクセスを効果的に管理し、メンバーが役割を果たすために必要な権限を持ちながら、エアギャップ環境のセキュリティを維持できます。
アクセス制御モデル
GDC は、アクセスを 3 つのコア コンポーネント（誰（ メンバー）、何（ ロール）、どこ（ リソース スコープ））を中心に構成します。
アクセス制御は、2 つの異なる段階で構成されます。1 つは本人確認（認証）、もう 1 つは実行できることの決定（認可）です。
- 認証: GDC はユーザー アカウントやパスワードを保存しません。GDC は、バンドルされている Keycloak ID プロバイダ（IdP）を活用するか、組織の IdP に接続して、認証情報でログインできるようにします。
- 認可: 認証後、GDC IAM は割り当てられたロールを確認して、アクセスできるリソースと実行できるアクションを決定します。
メンバー
メンバーは、リソースへのアクセス権を付与できる ID です。 GDC は、メンバーを管理する場所に基づいて、人間の ID と人間以外の ID の 2 つのカテゴリに分類します。
人間の ID
人間の ID は、GDC にログインするユーザーとグループです。GDC は、ユーザー アカウントやパスワードを保存するのではなく、バンドルされている Keycloak IdP を活用するか、OpenID Connect（OIDC）や SAML 2.0 などの標準の ID 連携プロトコルを使用して、組織の既存のログイン システム（Active Directory、LDAP、Okta など）に接続できます。
人間の ID には次の 2 種類があります。
- ユーザー: 認証情報を使用してシステムにログインする個々のユーザー。
- グループ: Keycloak または組織の 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 と連携するか、バンドルされている Keycloak
IdP で管理します。必要な IdP 接頭辞（例:
idpprefix-user@domain.com）を使用します。
|
Google アカウント（Gmail など）または Cloud Identity または Google Workspace を介して連携された企業 ID。 |
| 認可エンジン | 権限を評価して適用する基盤となるシステム。 | 主に Kubernetes ロールベース アクセス制御（RBAC）。アクセス リクエストは、ロール バインディングに対して API サーバーによってローカルで評価されます。 | Google のグローバル Cloud IAM サービス。リソース階層の任意のレベルでアタッチされたアクセス ポリシーに対して、API リクエストを一元的に評価します。 |
| ロール バインディング | 特定のロールにメンバーをマッピングする方法。 |
個々の IAMRoleBinding カスタム リソース。各バインディング
は、メンバーを 1 つのロールにリンクするオブジェクトです。IAM ロールの権限は純粋に付加的です。 |
各リソース、 フォルダ、組織にアタッチされた単一の IAM アクセス ポリシー。メンバーを ロールにマッピングする複数のバインディングが含まれており、条件付きルールまたは拒否ルールをサポートしています。 |
| サービス アカウント | アプリケーションと自動化されたワークロードで使用される人間以外の ID。 |
特定のプロジェクト
（ProjectServiceAccount）内に作成されたローカル サービス アカウント。公開鍵は
クラスタに保存され、秘密鍵はクライアントによってローカルで管理および保護されます。
|
Google によって一元的に管理されるグローバル ID。認証情報は Google によって自動的に管理されるか、鍵ファイルとしてダウンロードしてどこからでも認証できます。 |
| リソース階層 | リソースの整理と権限の継承に使用されるコンテナ構造。 | 2 階層: 組織 > プロジェクト | 多層階層: 組織 > フォルダ > プロジェクト |
| クライアント ツール | アクセスの管理に使用される主要なインターフェース、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 プロバイダに接続するをご覧ください。
- 環境にログインするには、 ログインするをご覧ください。
- 権限を付与してロール バインディングを管理するには、 アクセス権の付与と取り消しをご覧ください。