クラスタの信頼性

このページでは、クラスタ内の通信や、コントロール プレーンなどのコンポーネントに対するリクエストの認証方法など、Google Kubernetes Engine（GKE）クラスタの信頼モデルについて説明します。

このドキュメントは、GKE のクラスタ信頼モデルを理解する必要があるセキュリティ スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

このページを読む前に、次のことをよく理解しておいてください。

クラスタ間の通信

GKE では、以下に説明するとおり、クラスタのコンポーネント間のトラフィックにさまざまなセキュリティ メカニズムが適用されます。

  • コントロール プレーンとノード間のトラフィック: コントロール プレーンはコンテナを管理するためにノードと通信します。コントロール プレーンがノードに kubectl logs などのリクエストを送信すると、そのリクエストは Konnectivity プロキシ トンネルを介して送信されます。コントロール プレーンが送信するリクエストは、TLS で認証され、保護されます。ノードがコントロール プレーンにリクエストを送信する（たとえば kubelet から API サーバーへ）と、そのリクエストは相互 TLS により認証され、暗号化されます。

    新しく作成されたクラスタおよび更新されたクラスタはすべて、コントロール プレーンとノード間の通信に TLS 1.3 を使用します。コントロール プレーンとノード間の通信に対応する最小バージョンは、TLS 1.2 です。

  • ノード間のトラフィック: ノードは Compute Engine の VM です。 Google Cloud 本番環境ネットワーク内のノード間の接続には、認証と暗号化が適用されます。詳細については、転送データの暗号化に関するホワイトペーパーで VM 間の説明に関するセクションをご覧ください。

  • Pod 間のトラフィック: Pod が別の Pod にリクエストを送信しても、そのトラフィックはデフォルトでは認証されません。GKE では、ネットワーク レイヤにある異なるノードの Pod 間のトラフィックが暗号化されます。同じノードの Pod 間のトラフィックは、デフォルトでは暗号化されません。ネットワーク レイヤの暗号化の詳細については、Google Cloud の仮想ネットワーク暗号化と認証をご覧ください。

    Pod 間のトラフィックは NetworkPolicy で制限できます。Cloud Service Mesh などのサービス メッシュを使用すると、同じノード上のトラフィックを含むすべての Pod 間トラフィックを暗号化できます。また、別の方法でアプリケーション レイヤでの暗号化を行うことも可能です。

  • コントロール プレーンのコンポーネント間のトラフィック: コントロール プレーンで実行されるさまざまなコンポーネント間のトラフィックは、TLS を使用して認証および暗号化されます。トラフィックが、ファイアウォールで保護された Google 所有のネットワークを離れることはありません。

ルート オブ トラスト

GKE の構成は次のとおりです。

  • クラスタルート認証局（CA）は、API サーバーと kubelet のクライアント証明書を検証するために使用されます。つまり、コントロール プレーンとノードは同じ信頼のルートになります。クラスタ ノードプール内の kubelet のすべてがこの CA から、certificates.k8s.io API を使用して証明書署名リクエストを送信することにより証明書をリクエストできます。クラスタルート CA の存続期間で説明されているように、ルート CA の存続期間は限られています。
  • コントロール プレーン VM で etcd データベース インスタンスを実行するクラスタでは、クラスタごとの etcd ピア CA も使用され、etcd インスタンス間の信頼関係が確立されます。
  • すべての GKE クラスタでは、Kubernetes API サーバー間と etcd API 間の信頼を確立するために、個別の etcd API CA が使用されます。

API サーバーと kubelet

API サーバーと kubelet は、信頼に関してクラスタルート CA に依存しています。GKE では、コントロール プレーンの API 証明書がクラスタルート CA によって署名されます。各クラスタがそれぞれの CA を実行するため、あるクラスタの CA の信頼が損なわれても、他のクラスタ CA は影響を受けません。

内部サービスが管理するこの CA のルートキーは、エクスポートできません。このサービスが証明書署名リクエストを、各 GKE クラスタの kubelet からの同リクエストも含めて受け入れます。クラスタ内の API サーバーが信頼を損なっても、CA は信頼を損なわないため、他のクラスタは影響を受けません。

クラスタ内の各ノードには共有シークレットが作成時に挿入されるので、それを使用して証明書署名リクエストをクラスタルート CA に送信して kubelet クライアント証明書を取得できます。そしてこれらの証明書は、kubelet がそのリクエストを API サーバーに対して認証するために使用します。この共有シークレットには、Shielded GKE Nodes または Workload Identity Federation for GKE を有効にしない限り、ノード上の Pod から到達可能です。

クラスタルート CA の存続期間

クラスタルート CA の存続期間は限られているので、その後は期限切れの CA によって署名された証明書がすべて無効になります。認証情報の存続期間を確認するの手順に沿って、クラスタの CA のおおよその存続期限を確認します。

既存のルート CA が期限切れになる前に、認証情報を手動でローテーションする必要があります。CA が期限切れになり、認証情報をローテーションしないと、クラスタが復元不能な状態になる可能性があります。GKE には、復元できないクラスタを試して防ぐための次のメカニズムがあります。

  • クラスタが CA の期限切れの 7 日前に DEGRADED 状態になる

  • GKE は、CA の有効期限が切れる 30 日前に認証情報の自動ローテーションを試みます。この自動ローテーションでは、メンテナンスの時間枠は無視され、GKE が新しい認証情報を使用するノードを再作成すると、停止が発生する可能性があります。ローカル環境の kubectl などの外部クライアントは、新しい認証情報を使用するように更新するまで機能しません。

ローテーションを行う方法については、クラスタ認証情報をローテーションするをご覧ください。

クラスタの状態ストレージ

GKE クラスタでは、Kubernetes API オブジェクトの状態が Key-Value ペアとしてデータベースに保存されます。コントロール プレーンの Kubernetes API サーバーは、etcd API を使用してこのデータベースとやり取りします。GKE では、クラスタ状態データベースは次のいずれかのテクノロジーを使用して実行されます。

  • etcd: クラスタは、コントロール プレーン VM で実行される etcd インスタンスを使用します。
  • Spanner: クラスタは、コントロール プレーン VM の外部で実行される Spanner データベースを使用します。

クラスタで使用されているデータベース テクノロジーに関係なく、すべての GKE クラスタはコントロール プレーンで etcd API を提供します。クラスタ状態データベースに関連するトラフィックを暗号化するために、GKE では次のクラスタごとの CA のいずれかまたは両方を使用します。

  • etcd API CA: etcd API エンドポイントとの間のトラフィックの証明書の署名に使用されます。etcd API CA は、すべての GKE クラスタで実行されます。
  • etcd ピア CA: コントロール プレーンの etcd データベース インスタンス間のトラフィックの証明書に署名するために使用されます。etcd ピア CA は、etcd データベースを使用するすべてのクラスタで実行されます。Spanner データベースを使用するクラスタでは、etcd ピア CA は使用されません。

etcd API CA のルートキーは、コントロール プレーンが実行されている各 Compute Engine インスタンスのメタデータに配布されます。etcd API CA は、クラスタ間で共有されません。

etcd の CA 証明書は 5 年間有効です。これらの証明書が期限切れになる前に、GKE により自動的にローテーションが行われます。

証明書のローテーション

クラスタの API サーバーと kubelet の証明書すべてをローテーションするには、認証情報のローテーションを行います。etcd 証明書のローテーションをトリガーする方法はありません。これは GKE で管理されています。

次のステップ