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、または kubectl CLI を使用してカスタム リソース マニフェスト（YAML ファイル）を適用して、IAMRoleBinding を作成します。
たとえば、チームメンバーがプロジェクト内の仮想マシンを表示できるようにするには、そのプロジェクトのスコープで IAMRoleBinding を作成し、メンバーの ID を閲覧者のロールにリンクします。メンバーが仮想マシンを表示しようとすると、GDC はアクティブなロール バインディングを確認し、割り当てられたロールに必要な権限が含まれていることを確認して、リクエストを承認します。
GDC コンソールと gdcloud CLI はリソースに自動的に接続しますが、kubectl CLI を使用した直接 API アクセスでは、kubeconfig ファイルを生成して、そのリソースをホストする特定の Kubernetes クラスタまたは API サーバーに対して認証を行う必要があります。詳細については、ログインして kubeconfig ファイルを生成するをご覧ください。
ロール バインディングの管理の詳細については、アクセス権の付与と取り消しをご覧ください。
GDC エアギャップ IAM と Google Cloudの違い
Google Cloudでのアクセス管理の経験がある場合、GDC は同様のコンセプトを使用しますが、エアギャップのある Kubernetes ベースのインフラストラクチャ内で動作するように実装が異なります。
次の表に、GDC の IAM と Google Cloudの比較を示します。
| 機能 | 説明 | 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 ロールの権限は純粋に付加的なものです（拒否ルールは、組織のポリシーで個別に構成できます）。 |
各リソース、フォルダ、組織に 1 つの IAM アクセス ポリシーが適用されます。メンバーをロールにマッピングする複数のバインディングが含まれており、条件付きルールまたは拒否ルールをサポートしています。 |
| サービス アカウント | アプリケーションと自動化されたワークロードで使用される非人間 ID。 |
特定のプロジェクト（ProjectServiceAccount）内に作成されたローカル サービス アカウント。公開鍵はクラスタに保存され、秘密鍵はクライアントによってローカルで管理、保護されます。 |
Google によって一元管理されるグローバル ID。認証情報は、Google によって自動的に管理されるか、キーファイルとしてダウンロードされ、どこからでも認証できます。 |
| リソース階層 | リソースを整理し、権限を継承するために使用されるコンテナ構造。 | 2 階層: 組織 > プロジェクト | 多層階層: 組織 > フォルダ > プロジェクト |
| マルチゾーンの権限スコープ | 権限が評価され、アベイラビリティ ゾーンまたはリージョン間で伝播される方法。 | グローバル API サーバーによって管理される Kubernetes RBAC を使用します。これにより、ゾーン API サーバー間でロール バインディングが調整および複製されるため、デフォルトですべてのゾーンにアクセスが適用されます。 | フルマネージドのグローバル IAM サービスを採用しています。リソースレベルで割り当てられた権限は、本質的にグローバルであり、すべてのリージョンとゾーンに自動的に適用されます。 |
| クライアント ツール | アクセス管理に使用されるプライマリ インターフェース、CLI ツール、API。 | GDC コンソール、gdcloud CLI、KRM API。 | Google Cloud コンソール、gcloud CLI、REST API または gRPC API。 |
| API への直接アクセス | ツールとスクリプトが API を使用してリソースを直接管理するために認証する方法。 | kubectl CLI を使用して API に直接アクセスするには、kubeconfig ファイルを生成して、そのリソースをホストする特定の Kubernetes クラスタまたは API サーバーに対して認証を行う必要があります。（GDC コンソールと gdcloud CLI はリソースに自動的に接続します）。 |
gcloud または REST/gRPC エンドポイントを使用した直接 API アクセスでは、クラスタ固有のログインを必要とせずに、すべてのサービスにグローバルに適用される一元化された認証情報（gcloud auth login）が使用されます。 |
次のステップ
- 組織のログイン システムを接続するには、ID プロバイダに接続するをご覧ください。
- 環境にログインするには、ログインをご覧ください。
- 権限を付与してロール バインディングを管理するには、アクセス権の付与と取り消しをご覧ください。