コントロール プレーンのセキュリティ

このドキュメントでは、Google Kubernetes Engine でクラスタ コントロール プレーンのコンポーネントを保護する方法について説明します。

Google は、共有責任モデルに基づいて GKE コントロール プレーンのコンポーネントを管理します。コントロール プレーンには、Kubernetes API サーバー、etcd、複数のコントローラが含まれています。Google は、コントロール プレーンのセキュリティに対して責任を負いますが、お客様が自身の要件に基づいて特定のオプションを構成する場合もあります。その場合、ノード、コンテナ、ポッドの保護はお客様の責任で行っていただきます。

強化されたオペレーティング システム

GKE コントロール プレーンのコンポーネントは Container-Optimized OS で動作します。これは、Google が設計し、セキュリティを強化したオペレーティング システムです。Container-Optimized OS に組み込まれているセキュリティ機能の詳細については、Container-Optimized OS のセキュリティの概要をご覧ください。

アーキテクチャと分離

GKE クラスタでは、コントロール プレーンのコンポーネントは Google が所有する Compute Engine インスタンスで実行されます。このインスタンスは、Google が管理するプロジェクトに含まれています。各インスタンスでは、1 人のユーザーに対してのみコンポーネントが実行されます。

Kubernetes API サーバーや etcd の認証は、他の Google Cloud サービスと同じ方法で行われます。 この通信は、Application-layer Transport Security(ALTS)では保護されます。

クラスタに対する管理アクセス

Google サイト信頼性エンジニアによる SSH セッションは、Google の内部監査インフラストラクチャを介して監査ログに記録されます。この情報は、フォレンジックやセキュリティ対応で使用できます。詳細については、Google セキュリティ ホワイトペーパーの管理アクセスをご覧ください。

etcd のセキュリティ

Google Cloud Platform のデフォルトでは、コンテンツはファイル システムレイヤで暗号化されています。したがって、GKE クラスタの etcd ストレージをホストするディスクは、ファイル システム レイヤで暗号化されます。詳細については、保存時の暗号化をご覧ください。

etcd は 2 つの TCP ポートでリッスンします。ポート 2379 は、Kubernetes API サーバーなどの etcd クライアント用です。ポート 2379 はローカルのループバック ネットワーク インターフェースにバインドされています。このため、このポートには Kubernetes API サーバーを実行している VM からのみアクセス可能です。ポート 2380 はサーバー間の通信用です。ポート 2380 のトラフィックは相互 TLS によって暗号化されます。つまり、各サーバーは、他のサーバーに対して自身の ID を証明する必要があります。リージョン クラスタでは、クォーラムを確立するための etcd サーバー間の通信は相互 TLS によって暗号化されます。

認証局とクラスタの信頼性

クラスタには独自のルート認証局(CA)があります。 Google 内部サービスが、この CA のルートキーを管理します。クラスタには、etcd 用の独自の CA もあります。etcd CA のルートキーは、Kubernetes API サーバーを実行する VM のメタデータに配布されます。 ノードと Kubernetes API サーバーの間の通信は TLS で保護されます。詳細については、クラスタの信頼性をご覧ください。

脆弱性とパッチの管理

コントロール プレーンのテスト、認定、変更の段階的なロールアウトについて、GKE は Google の標準に準拠しています。これにより、コントロール プレーンのコンポーネントが使用不能になるリスクを最小限に抑えています。GKE は、可用性の詳細が定義されているサービスレベル契約に準拠しています。

GKE コントロール プレーンのコンポーネントは、Google サイト信頼性エンジニアのチームによって管理されています。最新のセキュリティ パッチを適用し、常に最新の状態を維持しています。たとえば、ホスト オペレーティング システム、Kubernetes コンポーネント、コントロール プレーン VM を実行するコンテナにパッチを適用しています。

GKE では、新しいカーネル、OS、Kubernetes レベルの修正がコントロール プレーン VM に速やかに適用されます。これらに既知の脆弱性に対する修正が含まれている場合、GKE のセキュリティに関する情報で詳細情報が提供されます。GKE は、Container Registry 脆弱性スキャンを使用して、すべての Kubernetes システムと GKE 固有のコンテナをスキャンし、コンテナに最新のパッチを適用します。これにより、Kubernetes エコシステム全体を保護します。

Google のエンジニアは、Kubernetes のセキュリティ バグの発見、修正、開示に参加しています。Google では、Google の脆弱性報奨プログラムにより、セキュリティ バグを発見した外部のセキュリティ研究者に報奨金を提供しています。2017 年 10 月の dnsmasq の脆弱性など、脆弱性が公開される前に、GKE で実行中のすべてのクラスタにパッチを適用できたケースもあります。

ユーザーが確認できる情報

このトピックで説明したセキュリティ機能は Google が管理しています。 このセクションと以降のセクションでは、ユーザーがモニタリングし、構成できるセキュリティ機能について説明します。

リリース 1.8.3 以降では、作成したクラスタに監査ロギングがデフォルトで有効になります。これは Stackdriver で利用可能なログで、Kubernetes API サーバーに対する呼び出しの詳細が記録されます。ログエントリは GCP Console の [ログ] ページで確認できます。また、BigQuery を使用してログの表示や分析を行うこともできます。

ユーザーが構成可能な機能

デフォルトでは、Kubernetes API サーバーはパブリック IP アドレスを使用します。マスター承認済みのネットワークプライベート クラスタを使用すると Kubernetes API サーバーを保護できます。プライベート クラスタでは、Kubernetes API サーバーにプライベート IP アドレスを割り当て、パブリック IP アドレスからのアクセスを遮断できます。

Cloud IAM を ID プロバイダとして使用すると、GKE でクラスタ認証を処理できます。MasterAuth 構成に空のユーザー名とパスワードを設定して基本認証を無効化する必要があります。同じ構成でクライアント証明書を無効にすると、クラスタへのアクセスを遮断する場合の考慮事項を 1 つ減らすことができます。

認証情報のローテーションを定期的に行うことで、コントロール プレーンのセキュリティを強化できます。認証情報のローテーションを開始すると、TLS 証明書とクラスタ認証局のローテーションが行われます。 GKE は、ユーザーの Kubernetes API サーバーの IP アドレスもローテーションします。詳細については、役割ベースのアクセス制御認証情報のローテーションをご覧ください。

次のステップ

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

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

Kubernetes Engine のドキュメント