GKE control plane authority について

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

GKE control plane authority 機能について

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

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

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

GKE control plane authority のメリット

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

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

GKE control plane authority の可用性

GKE control plane authority を使用できるリージョンとゾーンは、次のような機能を使用するかどうかによって異なります。

  • 顧客管理の暗号鍵を使用してコントロール プレーンのブートディスクを暗号化するには、クラスタが次のいずれかのリージョンにある必要があります。
    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4
  • GKE control plane authority で Confidential GKE Node を使用するには、クラスタが Hyperdisk Balanced の情報保護モードをサポートするリージョンに存在する必要があります。

これらの機能を使用しない場合は、任意の Trusted Cloud ロケーションで GKE control plane authority を使用できます。

GKE control plane authority の仕組み

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

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

鍵と認証情報の管理

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

GKE では、クラスタ内の ID の発行と検証、およびコントロール プレーン VM 内のデータの暗号化に、 Trusted Cloudのデフォルトではなくこれらの鍵と CA が使用されます。お客様が ID 発行とデータ暗号化の鍵に対する制御を維持しているときは、次のことができるようになります。

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

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

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

次のリソースを作成しておき、GKE による ID の発行時にこれらを使用します。

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

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

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

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

デフォルトでは、GKE はコントロール プレーン VM のブートディスクを暗号化します。コントロール プレーンが etcd データベース インスタンスを実行している場合、GKE は以下も暗号化します。

  • etcd データを保存するディスク。
  • etcd の Trusted Cloud by S3NS 内部オペレーションのバックアップ。

このデフォルトの暗号化では、 Trusted Cloud が管理する暗号鍵が使用されます。このデフォルトの暗号化の詳細については、デフォルトの保存データの暗号化をご覧ください。

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

  • コントロール プレーンのブートディスク: 各コントロール プレーン VM の起動に使用される Compute Engine ディスク。
  • etcd ディスク: 各コントロール プレーン VM にアタッチされ、クラスタ内の etcd インスタンスのデータを保存する Compute Engine ディスク。

  • etcd 内部オペレーション バックアップ: 障害復旧などのオペレーション上の目的で使用される etcd の、 Trusted Cloud 内部バックアップ。

    このバックアップは、緊急時における Trusted 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 サーバーに対して実行したアクションに関連するログ。
  • アクセスの透明性: コントロール プレーンへの接続と、 Trusted 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 によって実行されます。詳細については、コントロール プレーンのセキュリティをご覧ください。

次のステップ