GKE control plane authority について

Autopilot Standard

このページでは、マネージドコントロールプレーンのセキュリティの可視性と制御を強化するために Google Kubernetes Engine（GKE）が提供するオプションについて説明します。これらのオプションは、総称して GKE control plane authority と呼ばれます。このページは、機密データの処理に関する厳格なプライバシーとセキュリティのニーズを満たす情報セキュリティリーダー、コンプライアンス管理者、アナリストを対象としています。

GKE control plane authority 機能について

GKE では、保存中のストレージの暗号化、クラスタ内の認証情報を署名して検証する鍵と認証局（CA）の構成など、コントロールプレーンのセキュリティ構成を Google Cloud が完全に管理しています。GKE クラスタのコントロールプレーンノードは、Google Cloud が管理するプロジェクトにあります。Google Cloud が行う処理の詳細については、GKE の共有責任をご覧ください。

GKE control plane authority は、これらのフルマネージドコントロールプレーンノードの特定の側面を検証して管理できる、可視性と制御機能のセットです。これはオプションの機能です。これらの機能は、次のような要件がある場合に最適です。

金融、医療、行政機関など、特定のコンプライアンス要件がある規制の厳しい業界で活動している
厳格なセキュリティと暗号化の要件がある機密データを処理している
GKE の可視性を強化して、重要なワークロードの実行時の信頼性を高める必要がある
データの暗号化、ソフトウェアの完全性、ロギングに関連する特定のコンプライアンスまたは監査要件を満たす必要がある
重要なデータを処理する機密性の高いワークロードがあり、そのデータの暗号化とアクセスの可視性を確保したい
組織または規制の特定の要件を満たすカスタムセキュリティポリシーを適用する必要がある
GKE 環境の透明性と可視性を強化したい（特に、Google Cloud がコントロールプレーンで行うアクションに対して）

GKE control plane authority のメリット

GKE control plane authority 機能は、厳格なセキュリティポリシーや厳格な監査要件がある規制の厳しい環境に最適です。これらの機能には、次のようなメリットがあります。

可視性と制御の強化: GKE コントロールプレーンに対して追加の可視性、制御、暗号化機能を使用できます。
コンプライアンスの効率化: 詳細な監査ログとカスタマイズ可能なセキュリティポリシーを使用して、規制と業界の要件を満たすことができます。
信頼と透明性の向上: カスタマーサポートケースを解決する際に Google Cloud がコントロールプレーンで行うアクションに関する分析情報を取得できます。
リスクの軽減: 包括的なログを使用して、マネージドコントロールプレーンに対する潜在的な脅威を事前に検出して対応できます。
標準化された CA と鍵管理: Certificate Authority Service を使用して GKE クラスタ CA を管理します。これにより、証明書管理を特定のチームに委任し、CA ポリシーを包括的に適用できます。また、同様の管理委任を行うには、Cloud KMS を使用してコントロールプレーンのディスク暗号鍵を管理します。

GKE control plane authority の仕組み

コントロールプレーンで使用できる機能は、次のように、必要な制御の種類に基づいて分類されます。これらの機能は、特定の要件に応じて 1 つ以上使用できます。

鍵と認証情報の管理: GKE がコントロールプレーンで保存データの暗号化に使用したり、クラスタで ID を発行して検証するために使用する鍵を管理します。
アクセスログと ID 発行ログ: ネットワーク、VM、アクセスの透明性からのログを使用し、複数のソースを使用して GKE コントロールプレーンへのアクセスを検証します。Cloud KMS と CA サービスの ID 発行ログを利用して、管理する鍵と CA によって ID が発行された日時を確認します。詳細な Kubernetes API 使用状況ログを使用して、これらの ID がクラスタで何を行っているかを追跡します。

鍵と認証情報の管理

デフォルトでは、Google Cloud が GKE クラスタ内の鍵と CA を管理します。必要に応じて、Cloud KMS と CA Service を使用して独自の鍵と CA を設定できます。これらの鍵と CA は、新しいクラスタの作成時に使用します。

GKE は、クラスタ内の ID の発行と検証、コントロールプレーン VM 内のデータの暗号化に、Google Cloud のデフォルトではなく、これらの鍵と CA を使用します。ID 発行鍵とデータ暗号鍵を管理し続けることで、次のようなことができます。

鍵に対する排他的制御を義務付けるデータ主権とプライバシーに関する規制を遵守する
独自の暗号鍵を管理して、Kubernetes の重要な機密データの暗号化を制御する
ハードウェア格納型キーの使用要件など、組織のポリシーと要件に基づいてデータ暗号化戦略をカスタマイズする

セルフマネージド CA とサービスアカウントキー

管理する Cloud KMS 鍵と CA Service CA を使用するように GKE コントロールプレーンを構成できます。GKE はこれらのリソースを使用して、クラスタ内の ID を発行して検証します。たとえば、GKE は CA とキーを使用して、Kubernetes クライアント証明書と Kubernetes サービスアカウント署名なしトークンを発行します。

GKE が ID の発行時に使用する次のリソースを作成します。

サービスアカウント署名鍵: クラスタ内のサービスアカウントの Kubernetes ServiceAccount 署名付きトークンに署名します。これらの署名なしトークンは、Kubernetes API サーバーとの Pod 通信を容易にする JSON Web Token（JWT）です。
サービスアカウントの検証鍵: Kubernetes サービスアカウントの JWT を検証します。この鍵は通常、署名鍵と同じですが、鍵をより安全にローテーションできるように別途構成されます。
クラスタ CA: 証明書署名リクエスト（CSR）や kubelet 通信などの目的で署名付き証明書を発行します。
etcd ピア CA: クラスタ内の etcd インスタンス間の通信用に署名付き証明書を発行します。
etcd API CA: etcd API サーバーとの通信用に署名付き証明書を発行します。
集約 CA: Kubernetes API サーバーと拡張機能サーバー間の通信を有効にするために、署名付き証明書を発行します。

GKE がクラスタで ID を発行すると、Cloud Logging に対応する監査ログが作成されます。このログを使用して、発行された ID の存続期間を追跡できます。

詳細については、GKE で独自の認証局と署名鍵を実行するをご覧ください。

コントロールプレーンのブートディスクと etcd の暗号化

デフォルトでは、GKE は Google Cloud が管理する暗号鍵を使用して、コントロールプレーン VM のブートディスク、etcd にデータを保存するディスク、etcd の Google Cloud 内部運用バックアップを暗号化します。このデフォルトの暗号化の詳細については、デフォルトの保存データの暗号化をご覧ください。

必要に応じて、Cloud KMS を使用して管理する独自の暗号鍵を使用して、次のリソースを暗号化できます。

コントロールプレーンのブートディスク: 各コントロールプレーン VM が起動に使用する Compute Engine ディスク。
etcd ディスク: 各コントロールプレーン VM にアタッチされ、クラスタ内の etcd インスタンスのデータを保存する Compute Engine ディスク。
etcd 内部オペレーションバックアップ: 障害復旧などのオペレーション目的で使用される etcd の内部 Google Cloud バックアップ。

このバックアップは、Google Cloud 内部の緊急的な対策です。クラスタをバックアップして復元する場合は、代わりに Backup for GKE を使用します。

手順については、etcd とコントロールプレーンのブートディスクを暗号化するをご覧ください。

この追加のオプションの暗号化は、クラスタコントロールプレーンでの暗号化手段の制御に関連する特定の規制要件またはコンプライアンス要件を満たす必要がある場合に最適です。独自の鍵を使用して、クラスタ内のワーカーノードのブートディスクとストレージディスクを暗号化できます。詳細については、顧客管理の暗号鍵（CMEK）を使用するをご覧ください。

GKE control plane authority を使用してコントロールプレーンのブートディスクを暗号化すると、GKE コントロールプレーン VM はブートディスクで Hyperdisk Balanced の情報保護モードを自動的に使用します。この構成では、ワーカーノードのデフォルトのブートディスクは変更されません。

アクセスログと ID 発行ログ

Logging では、コントロールプレーンのアクセスと ID に関連するすべてのイベントのログを確認できます。たとえば、次のようなイベントを確認できます。

直接アクセス: GKE コントロールプレーンノードへの直接アクセスの試行（SSH など）に関連するログ。VM SSH ログと VM ネットワーク接続がアクセスの透明性ログの SSH レコードと一致することを確認できます。
ID の発行と検証: CA Service と Cloud KMS で管理する CA と鍵によって発行された ID に関連するログ。
Kubernetes での ID の使用: 特定の ID が Kubernetes API サーバーに対して実行したアクションに関連するログ。
アクセスの透明性: コントロールプレーンへの接続と、Google Cloud の担当者がコントロールプレーンで行ったアクションに関連するログ。

これらのログは、次のような場合に役立ちます。

コンプライアンスとセキュリティを確保するために、すべてのコントロールプレーンアクセスと ID イベントの包括的な監査証跡を維持します。
Google の組み込み保護機能に加えて、独自のモニタリングを構築して、コントロールプレーン内の不審なアクティビティを特定して調査できます。
承認されたエンティティのみが GKE クラスタにアクセスして操作できるようにすることで、セキュリティポスチャーを強化します。
Cloud KMS と CA Service の ID 発行ログを使用して、管理する鍵と CA によって ID が作成された日時を確認します。詳細な Kubernetes API 使用状況ログを使用して、これらの ID がクラスタで何を行っているかを追跡します。

次のドキュメントでは、さまざまなタイプのコントロールプレーンログを表示して処理する方法について説明しています。

コントロールプレーンのセキュリティに関するその他のリソース

このセクションでは、コントロールプレーンのセキュリティの信頼性を高めるために使用できるその他の方法について説明します。次のリソースを使用するために、GKE control plane authority を使用する必要はありません。

コントロールプレーンの VM イメージの整合性: GKE は、ノード VM の作成イベントと起動イベントの詳細なログを Cloud Logging に追加します。また、コントロールプレーンとワーカーノードのマシンイメージに対応する SLSA VSA を GitHub で公開しています。VM が対応する VSA を持つ OS イメージを使用していることを確認し、各コントロールプレーン VM の起動時の整合性を検証できます。

VM の整合性検証を行うには、GKE コントロールプレーンの VM の整合性を検証するをご覧ください。
組み込みのコントロールプレーンのセキュリティ対策: GKE は、マネージドコントロールプレーンでさまざまなセキュリティ強化対策を実行します。詳細については、コントロールプレーンのセキュリティをご覧ください。