このドキュメントでは、Google Kubernetes Engine（GKE）がクラスタ コントロール プレーン コンポーネントを保護する方法について説明します。
Google は、共有責任モデルに基づいて GKE コントロール プレーン コンポーネントを管理します。コントロール プレーンには、Kubernetes API サーバー、etcd ストレージ、その他のコントローラが含まれています。Google は、コントロール プレーンのセキュリティに対して責任を負いますが、お客様が自身の要件に基づいて特定のオプションを構成する場合もあります。その場合、ノード、コンテナ、ポッドの保護はお客様の責任で行っていただきます。
強化されたオペレーティング システム
GKE コントロール プレーン コンポーネントは Container-Optimized OS で動作します。これは、Google が設計し、セキュリティを強化したオペレーティング システムです。Container-Optimized OS に組み込まれているセキュリティ機能の詳細については、Container-Optimized OS のセキュリティの概要をご覧ください。
アーキテクチャと分離
GKE クラスタでは、コントロール プレーン コンポーネントは Google が所有する Compute Engine インスタンスで実行されます。このインスタンスは、Google 管理のプロジェクトに含まれています。各インスタンスでは、1 人のユーザーに対してのみコンポーネントが実行されます。
クラスタ コンポーネントの相互認証について詳しくは、クラスタの信頼性をご覧ください。
プロジェクトに対するコントロール プレーン アクセス
GKE は、Kubernetes Engine サービス エージェントという名前の Google 管理サービス アカウントを使用して、ノード、ディスク、ロードバランサなど、ユーザーに代わってクラスタ リソースを有効にします。サービス アカウントには、プロジェクトの Kubernetes Engine サービス エージェントのロール（roles/container.serviceAgent）が自動的に付与されます。
Kubernetes Engine サービス エージェントには、次のメールアドレスがあります。
service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
このメールアドレスで、PROJECT_NUMBER はプロジェクト番号です。
クラスタに対する管理者権限
Google サイト信頼性エンジニアによる SSH セッションは、Google の内部監査インフラストラクチャを介して監査ログに記録されます。この情報は、フォレンジックやセキュリティ対応で使用できます。詳細については、Google セキュリティ ホワイトペーパーの管理アクセスをご覧ください。
etcd のセキュリティ
Google Cloud では、お客様のコンテンツがデフォルトでファイル システム レイヤで暗号化されます。したがって、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 は、Artifact Analysis を使用して、すべての Kubernetes システムと GKE 固有のコンテナの脆弱性をスキャンし、コンテナに最新のパッチを適用します。これにより、Kubernetes エコシステム全体を保護します。
Google のエンジニアは、Kubernetes のセキュリティ バグの発見、修正、開示に参加しています。また、Google では、Google の脆弱性報奨プログラムにより、セキュリティ バグを発見した外部のセキュリティ研究者に報奨金を提供しています。2017 年 10 月の dnsmasq の脆弱性など、脆弱性が公開される前に、GKE で実行中のすべてのクラスタにパッチを適用できたケースもあります。
ユーザーが確認できる情報
このトピックで説明したセキュリティ機能は Google が管理しています。 このセクションと以降のセクションでは、ユーザーがモニタリングし、構成できるセキュリティ機能について説明します。
GKE バージョン 1.8.3 以降では、作成したクラスタの監査ロギングがデフォルトで有効になります。これにより、Google Cloud Observability で利用可能な詳細なレコードで、Kubernetes API サーバーに対して行われた呼び出しを確認できます。ログエントリは、Google Cloud コンソールのログ エクスプローラで確認できます。また、BigQuery を使用してログの表示や分析を行うこともできます。
ユーザーが構成可能な機能
デフォルトでは、Kubernetes API サーバーはパブリック IP アドレスを使用します。承認済みのネットワークとプライベート クラスタを使用すると Kubernetes API サーバーを保護できます。プライベート クラスタでは、Kubernetes API サーバーにプライベート IP アドレスを割り振り、パブリック IP アドレスからのアクセスを遮断できます。
IAM を ID プロバイダとして使用すると、GKE でクラスタ認証を処理できます。認証のセキュリティを強化するため、GKE 1.12 以降で作成されたクラスタでは、基本認証とクライアント証明書の発行がデフォルトで無効になります。
認証情報のローテーションを定期的に行うことで、コントロール プレーンのセキュリティを強化できます。認証情報のローテーションを開始すると、TLS 証明書とクラスタ認証局のローテーションが行われます。GKE は、ユーザーの Kubernetes API サーバーの IP アドレスもローテーションします。詳細については、ロールベースのアクセス制御（RBAC）と認証情報のローテーションをご覧ください。