クラスタの信頼性

このページでは、Google Kubernetes Engine クラスタにおける信頼について、マスターとノードがどのようにリクエストを認証するかも含めて説明します。

クラスタ間の通信

クラスタには、Kubernetes のコンポーネント間で通信するための数多くの接続があります。

マスターとノードの間
マスターはコンテナを管理するためにノードと通信します。マスターがノードに、たとえば kubectl ログなどのリクエストを送信すると、そのリクエストは SSH トンネルで送信され、さらに未認証の TLS で保護されて、整合性と暗号化が得られます。ノードがマスターに(たとえば kubelet から API サーバーへ)リクエストを送信すると、そのリクエストは相互 TLS を使用して認証され、暗号化されます。
ノード間
ノードは、特定のワークロードの一環として別のノードと通信することがあります。ノードが別のノードにリクエストを送信すると、そのリクエストは認証されます。そして、その接続が Google により管理される物理的な境界を超える場合、リクエストは暗号化されます。Kubernetes コンポーネントはノード間通信を必要としないことに注意してください。詳しくは、転送データの暗号化のホワイトペーパーをご覧ください。
ポッド間
ポッドは、特定のワークロードの一環として別のポッドと通信することがあります。ポッドが別のポッドに送信したリクエストは、認証も暗号化もされません。Kubernetes コンポーネントはポッド間通信を必要としないことに注意してください。ポッド間トラフィックはネットワーク ポリシーで制限でき、Istio などのサービス メッシュを使用して暗号化するか、アプリケーション レイヤ暗号化を実装できます。
etcd 間
etcd のインスタンスは、状態を最新に保つために別の etcd のインスタンスと通信することがあります。etcd のインスタンスが別のインスタンスにリクエストを送信すると、そのリクエストは相互 TLS を使用して認証され、暗号化されます。トラフィックは、ファイアウォールで保護された GKE 所有のネットワークを出ることがありません。
マスターと etcd の間
この通信は全体がローカルホスト上で行われるので、認証も暗号化もされません。

信頼のルート

GKE は、以下のように構成されています。

  • クラスタルート認証局(CA)は、API サーバーと kubelet のクライアント証明書を検証するために使用されます。つまり、マスターとノードは信頼のルートが同じです。クラスタノード プール内の kubelet のすべてがこの CA から、certificates.k8s.io API を使用して証明書署名リクエストを送信することにより証明書をリクエストできます。
  • 別のクラスタ毎の etcd CA が、etcd の証明書を検証するために使用されます。

API サーバーと kubelet

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

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

クラスタ内の各ノードには共有シークレットが作成時に挿入されるので、それを使用して証明書署名リクエストをクラスタルート CA に送信して kubelet クライアント証明書を取得できます。そしてこれらの証明書は、kubelet がそのリクエストを API サーバーに対して認証するために使用します。この共有シークレットは、メタデータ隠蔽が有効になっていなければ、ポッドによって到達可能であるので注意してください。

API サーバーと kubelet の証明書は 5 年間有効ですが、認証情報のローテーションを行うことにより早く手動でローテーションできます。

etcd

etcd は GKE における信頼に関して、別個のクラスタ毎 etcd CA に依存しています。

etcd CA のルートキーは、マスターが実行されている各 VM のメタデータに配布されます。マスター VM で実行されるコード、あるいはこれらの VM のメタデータの計算にアクセスするコードが、この CA として証明書に署名できます。クラスタ内の etcd の信頼が損なわれも、CA はクラスタ間で共有されないため、他のクラスタは影響を受けません。

etcd の証明書は 5 年間有効です。

証明書をローテーションする

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント