デザインの権限設定

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ ユニバースでの権限付与設計のベスト プラクティスについて説明します。この記事のトピックは次のとおりです。

以下の設計は推奨されていますが、規定どおりに正確に準拠する必要はありません。各 GDC ユニバースには、ケースバイケースで満たす必要がある固有の要件と考慮事項があります。

組織ごとに ID プロバイダを構成する

オペレーターは、組織ごとに 1 つ以上の ID プロバイダを構成する必要があります。次に、管理者が ID プロバイダに接続して、GDC ユニバース内のアプリケーションの認証サービスを管理します。

会社に複数の部門があり、それぞれに個別の組織が存在し、各組織が認証のために同じ ID プロバイダに接続するシナリオが考えられます。その場合は、ユーザーが組織全体で持つ権限の組み合わせを把握し、監査する必要があります。複数の組織で権限を持つユーザーが、ワークロードを個別の組織に分離するための要件に違反していないことを確認します。

また、複数のベンダーチームが 1 つの組織で共同作業を行う場合など、異なるユーザーセットが異なる ID プロバイダを使用して 1 つの組織内で認証を行うシナリオもあります。ユーザー ID を単一の ID プロバイダに統合するか、個別の ID プロバイダを維持するかを検討し、会社の ID 管理アプローチに最適な方法を選択します。

ID プロバイダの多要素認証を構成する

GDC は、多要素認証などの追加のセキュリティ設定を含む認証を IAM プラットフォームに依存しています。機密性の高いリソースにアクセスする可能性のあるユーザーに対して、物理キーを使用した多要素認証を構成することをおすすめします。

マネージド サービスとマーケットプレイス サービスを制限する

プロジェクト内の潜在的な攻撃対象領域を制限したり、未承認のサービスの使用を回避したりするために、特定のサービスから一部のプロジェクトをブロックすることをおすすめします。デフォルトでは、AI や ML などのマネージド サービスは、どのプロジェクトでも使用できます。マネージド サービスと比較すると、マーケットプレイス サービスはまず組織で有効にする必要があります。

プロジェクトからのサービス アクセスを拒否するには、サービスのカスタム リソース定義と Namespace のリストに Gatekeeper の制約を適用します。Gatekeeper でアクセスを拒否する方法は、マネージド サービスとマーケットプレイス サービスに適用されます。

複数のクラスタの kubeconfig ファイルを管理する

運用タスクが異なれば、異なるクラスタへの接続が必要になります。たとえば、IAM ロールをプロジェクトにバインドするタスクや、Kubernetes クラスタに Kubernetes Pod リソースをデプロイするタスクなどを行います。

GDC コンソールを使用する場合、GDC コンソールはクラスタへの接続などの低レベルのオペレーションを抽象化するため、どの基盤となるクラスタがタスクを実行するかを意識する必要はありません。

ただし、gdcloud CLI または kubectl CLI を使用する場合は、タスクを完了するために複数の kubeconfig ファイルが必要になることがあります。タスクに適したクラスタの kubeconfig 認証情報を使用してログインしていることを確認します。

Kubernetes サービス アカウントのベスト プラクティス

Kubernetes サービス アカウントの場合、認可はシークレット トークンに基づきます。サービス アカウント トークンのリスクを軽減するには、次のベスト プラクティスを検討してください。

  • GDC の外部で使用するために、永続的なサービス アカウント認証情報をダウンロードしないでください。
  • Pod を作成および編集できるユーザーまたはサービス アカウントの Kubernetes エスカレーション パスに注意してください。
  • ワークロードのサービス アカウント トークン プロジェクションの expirationSeconds フィールドを短い期間に設定します。
  • サービス アカウントの認証情報を定期的にローテーションする。

最小権限の原則を検討する

ユーザーにロール バインディングを付与する場合は、最小権限の原則（PoLP）を考慮してください。PoLP に従って、タスクの完了に必要な権限のみを割り当てることを検討してください。

たとえば、単一のプロジェクト内で IAM プロジェクト管理者ロールをユーザーに付与すると、このユーザーはそのプロジェクト内でロールを付与する権限を委任します。このユーザーは、使用する特定のサービスに基づいて、プロジェクト内の他のデベロッパーにきめ細かいロールを付与します。IAM プロジェクト管理者ロールは、プロジェクトで自分自身または他のユーザーに追加のロールを付与して権限を昇格するために使用できるため、信頼できるリーダーに制限する必要があります。

過剰な権限がないか定期的に監査する

組織内で付与されているロールを確認し、過剰な権限がないか監査してください。付与されたロールが個々のユーザーが業務を完了するために必要であること、プロジェクト間のロールの組み合わせがエスカレーションや引き出しのリスクにつながらないことを確認する必要があります。

会社で複数の組織を使用している場合、個々のユーザーに複数の組織にまたがる高い権限を持つロールを付与することはおすすめしません。これは、そもそも組織を分離する理由に反する可能性があるためです。