このドキュメントでは、Google Distributed Cloud（GDC）のエアギャップ環境における権限設計のベスト プラクティスについて説明します。この記事のトピックは次のとおりです。
- 組織ごとの ID プロバイダ（IdP）
- IdP の多要素認証
- マネージド サービスとマーケットプレイス サービス
- クラスタ kubeconfig の管理
- Kubernetes サービス アカウント
- 最小権限の原則
- 過剰な権限に対する定期的な監査
次の設計が推奨されますが、記載されているとおりに厳密に実施する必要はありません。各 GDC 環境には固有の要件と考慮事項があり、個別に満たす必要があります。
組織ごとに ID プロバイダを構成する
オペレーターは、組織ごとに 1 つ以上の ID プロバイダを構成する必要があります。管理者は、ID プロバイダに接続して、 GDC 環境内の アプリケーションの認証サービスを管理します。
会社に複数の部門があり、それぞれが別々の組織に属している場合、各組織は認証のために同じ ID プロバイダに接続します。この場合、ユーザーが組織全体で持つ権限の組み合わせを把握して監査する必要があります。複数の組織で権限を持つユーザーが、ワークロードを個別の組織に分離するための要件に違反しないようにしてください。
また、複数のベンダーチームが 1 つの組織で連携している場合など、異なるユーザーセットが異なる ID プロバイダを使用して単一の組織内で認証を行うシナリオも考えられます。ユーザー ID を単一の ID プロバイダに統合するか、別々の ID プロバイダを維持する方が、会社の ID 管理アプローチに適しているかどうかを検討してください。
ID プロバイダの多要素認証を構成する
GDC は、IAM プラットフォームを使用して認証を行います。これには、多要素認証などの追加のセキュリティ設定が含まれます。機密リソースにアクセスする可能性のあるユーザーには、物理キーを使用して多要素認証を構成することをおすすめします。
マネージド サービスとマーケットプレイス サービスを制限する
プロジェクトの潜在的な攻撃対象領域を制限したり、承認されていないサービスの使用を回避したりするために、一部のプロジェクトを特定のサービスからブロックすることをおすすめします。 デフォルトでは、人工知能や機械学習などのマネージド サービスは、どのプロジェクトでも使用できます。マネージド サービスとは異なり、マーケットプレイス サービスは、まず組織で有効にする必要があります。
プロジェクトからのサービス アクセスを拒否するには、 Gatekeeper 制約をサービスの カスタム リソース定義と Namespace のリストに対して適用します。Gatekeeper を使用してアクセスを拒否する方法は、マネージド サービスとマーケットプレイス サービスに適用されます。
複数のクラスタの kubeconfig ファイルを管理する
さまざまな運用タスクでは、異なるクラスタへの接続が必要です。たとえば、IAM ロールをプロジェクトにバインドするタスクや、Kubernetes
クラスタに Kubernetes Pod リソースをデプロイするタスクなどがあります。
GDC コンソールを使用する場合、GDC コンソールはクラスタへの接続などの低レベルのオペレーションを抽象化するため、タスクを実行する基盤となるクラスタを意識する必要はありません。
ただし、gdcloud CLI または kubectl CLI を使用する場合は、タスクを完了するために複数の kubeconfig ファイルが必要になることがあります。タスクに適したクラスタの kubeconfig 認証情報を使用して ログインしてください。
Kubernetes サービス アカウントのベスト プラクティス
Kubernetes サービス アカウントの場合、承認はシークレット トークンに基づいています。サービス アカウント トークンのリスクを軽減するには、次のベスト プラクティスを検討してください。
- GDC の外部で使用するために、永続的なサービス アカウント認証情報をダウンロードしないようにします。
- Pod の作成と編集ができるユーザーまたはサービス アカウントの Kubernetes エスカレーション パス に注意してください。
- ワークロードのサービス アカウント トークン プロジェクションの
expirationSecondsフィールドを短い期間に設定します。 - サービス アカウント認証情報を定期的にローテーションします。
最小権限の原則を検討する
ユーザーに ロール バインディングを付与する場合は、最小権限の原則（PoLP）を検討してください。PoLP に従って、タスクの完了に必要な権限のみを割り当てることを検討してください。
たとえば、単一のプロジェクト内でプロジェクト IAM 管理者ロールをユーザーに付与すると、そのユーザーはプロジェクト内でロールを付与する権限を委任できます。 このユーザーは、使用する特定のサービスに基づいて、プロジェクト内の他のデベロッパーに詳細なロールを付与します。プロジェクト IAM 管理者ロールは、信頼できるリードに制限する必要があります。このロールを使用して権限を昇格させ、自分自身や他のユーザーにプロジェクト内の追加のロールを付与できるためです。
過剰な権限がないか定期的に監査する
組織内で付与されたロールを確認し、過剰な権限がないか監査してください。付与されたロールが個々のユーザーの職務を完了するために必要なものであり、プロジェクト間のロールの組み合わせがエスカレーションやデータ漏洩のリスクにつながっていないことを確認する必要があります。
会社で複数の組織を使用している場合、個々のユーザーが複数の組織で高度な権限を持つロールを持つことはおすすめしません。これは、組織を分離する理由に違反する可能性があるためです。