このページでは、GKE On-Prem のインフラストラクチャの各レイヤに含まれるセキュリティ機能と、ニーズに合わせてセキュリティ機能を構成する方法について説明します。
概要
GKE On-Prem は、コンテナ イメージのコンテンツ、コンテナ ランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなどのワークロードを保護することを目的としたいくつかの機能を備えています。
クラスタとワークロードの保護には、階層的なアプローチをおすすめします。ユーザーとワークロードに付与するアクセスレベルに対して最小権限の原則を適用できます。柔軟性とセキュリティの適切なレベルについてトレードオフを見極める必要があります。
認証と認可
OpenID Connect（OIDC）（kubectl 経由）または Cloud Console から Kubernetes サービス アカウント トークンを使用して、GKE On-Prem のクラスタに対して認証を行います。
クラスタレベルまたは Kubernetes 名前空間内で Kubernetes リソースへのアクセス権限を詳細に構成するには、Kubernetes のロールベースのアクセス制御（RBAC）を使用します。RBAC では、ユーザーとサービス アカウントにアクセスを許可するオペレーションとリソースを定義する詳細なポリシーを作成できます。RBAC では、指定された任意の検証済み ID に対するアクセスを制御できます。
Kubernetes Engine の認証と認可の戦略をさらに簡素化、合理化するには、GKE On-Prem で、以前の属性ベースのアクセス制御（ABAC）を無効にします。
コントロール プレーンのセキュリティ
コントロール プレーン コンポーネントには、Kubernetes API サーバー、スケジューラ、コントローラ、Kubernetes 構成が永続化される etcd データベースが含まれます。Kubernetes Engine において、Kubernetes のコントロール プレーン コンポーネントの管理と保守は Google によって行われますが、GKE On-Prem のコントロール プレーン コンポーネントはローカルの管理者が管理します。
GKE On-Prem では、コントロール プレーン コンポーネントは企業ネットワーク内で実行されます。既存の企業ネットワーク ポリシーとファイアウォールを使用して、GKE On-Prem の API サーバーを保護できます。プライベート IP アドレスを API サーバーに割り当てて、プライベート アドレスへのアクセスを制限することもできます。
GKE On-Prem の通信はすべて、TLS チャネルを介して行われます。TLS チャネルは、etcd、cluster、org の 3 つの認証局（CA）によって管理されます。
- etcd CA は、API サーバーから etcd レプリカへの通信と、etcd レプリカ間のトラフィックを保護します。この CA は自己署名です。
- クラスタ CA は、API サーバーとすべての内部 Kubernetes API クライアント（kubelet、コントローラ、スケジューラ）間の通信を保護します。この CA は自己署名です。
- org CA は、Kubernetes API を外部ユーザーに提供するために使用される外部 CA です。この CA はユーザーが管理します。
管理コントロール プレーンの場合、鍵はコントロール プレーンのノードに保存されます。ユーザー クラスタの場合、鍵は管理コントロール プレーンに Kubernetes Secret として保存されます。API サーバーは、org CA によって署名されたユーザー指定の証明書で構成されます。API サーバーは、Server Name Indication（SNI）を使用して、クラスタ CA によって署名された鍵、または org CA によって署名された鍵のいずれを使用するかを決定します。
GKE On-Prem のクラスタ認証は、証明書とサービス アカウント署名なしトークンによって処理されます。管理者は、OIDC、または管理者証明書（初期ロール バインディングの作成や緊急時に使用）を使用してコントロール プレーンに対して認証します。
証明書のローテーションは次のように行われます。
- API サーバー、コントロール プレーン、ノードの場合、アップグレードごとに証明書が作成またはローテーションされます。
- CA はほとんどローテーションされない、またはオンデマンドでローテーションされる場合があります。
ノードのセキュリティ
GKE On-Prem は、クラスタにノードとして接続されている VMware インスタンスにワークロードをデプロイします。以降のセクションでは、GKE On-Prem で利用可能なノードレベルのセキュリティ機能を活用する方法を説明します。
Ubuntu
GKE On-Prem は、Kubernetes コントロール プレーンとノードを実行するオペレーティング システムとして、最適化されたバージョンの Ubuntu を使用します。Ubuntu には最新のセキュリティ機能が豊富に用意されており、GKE On-Prem では次のようなクラスタ向けのセキュリティ強化機能が実装されています。
- 最適化されたパッケージのセット。
- Google Cloud 向けにカスタマイズされた Linux カーネル。
- OS の自動セキュリティ更新（省略可）。
- 制限付きユーザー アカウントと root ログインの無効化。
Ubuntu には、次のような別のセキュリティ ガイドも用意されています。
ノードのアップグレード
ノードは定期的にアップグレードする必要があります。コンテナのランタイム、Kubernetes 自体、ノードのオペレーティング システムのセキュリティに問題が発生すると、ノードの緊急アップグレードが必要となる場合があります。クラスタをアップグレードすると、各ノードのソフトウェアが最新バージョンにアップグレードされます。
ワークロードの保護
Kubernetes では、コンテナベースのワークロードのプロビジョニング、スケーリング、更新を迅速に行うことができます。このセクションでは、管理者とユーザーが実行中のコンテナの能力を制限して、クラスタ内の他のコンテナ、実行中のホスト、プロジェクトで有効になっている GCP サービスを制御する方法について説明します。
Pod コンテナのプロセス権限を制限する
コンテナ化されたプロセスの権限を制限することは、クラスタの全体的なセキュリティにとって重要です。Kubernetes Engine では、Pod とコンテナの両方でセキュリティ コンテキストを使用してセキュリティ関連のオプションを設定できます。これらの設定により、次のようなプロセスのセキュリティ設定を変更できます。
- 実行するユーザーとグループ
- 利用可能な Linux 機能
- 権限昇格
こうした設定を Pod レベルまたはコンテナレベルではなくクラスタレベルで変更するには、PodSecurityPolicy リソースを作成する必要があります。PodSecurityPolicy により、クラスタ内のすべての Pod がここで定義した最小限のベースライン ポリシーを遵守するようにできます。
デフォルトの GKE On-Prem ノードのオペレーティング システムである Ubuntu は、Kubernetes が起動したすべてのコンテナにデフォルトの Docker AppArmor セキュリティ ポリシーを適用します。プロファイルのテンプレートは GitHub で確認できます。特に、次のプロファイルではコンテナに対する以下の機能が拒否されます。
- プロセス ID ディレクトリ（/proc/）内のファイルに直接書き込むこと。
- /proc/ に存在しないファイルへの書き込み。
- /proc/sys 内の /proc/sys/kernel/shm* 以外のファイルへの書き込み。
- ファイル システムをマウントする
監査ロギング
Kubernetes Audit logging は、管理者が GKE On-Prem 環境で発生したイベントの保持、クエリ、処理、アラート生成を行う手段を提供します。管理者はログに記録された情報を使用して、フォレンジック分析、リアルタイム アラート、Kubernetes Engine クラスタの使用状況とユーザーのカタログを作成できます。
デフォルトでは、GKE On-Prem は管理アクティビティをログに記録します。また、検査対象のオペレーションの種類によってはデータアクセス イベントを記録することもできます。
Connect Agent は、オンプレミスで実行されるローカル API サーバーとのみ通信し、各クラスタには独自の監査ログのセットが必要です。ユーザーが UI から実行するすべてのアクションは、そのクラスタによってログに記録されます。
暗号化
Google の Cloud Key Management Service（Cloud KMS）は、クラウドでホストされる鍵管理サービスです。このサービスを利用することで、サービスの暗号鍵を管理できます。AES256、RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384 の各規格に対応し、暗号鍵の生成、使用、ローテーション、破棄をサポートしています。Cloud KMS は Cloud IAM と Cloud Audit Logging に統合されているため、個々の鍵の権限を管理し、それらの用途をモニタリングできます。Cloud KMS を使用して、Secret や保存する必要がある他の機密データを保護します。
GKE On-Prem のクラスタとワークロードが Cloud VPN 経由で Google Cloud サービスに安全に接続されている場合は、Cloud KMS を使用して鍵を管理できます。それ以外の場合は、次の代替方法のいずれかを選択します。
- Kubernetes Secret
- HashiCorp Vault
- ハードウェア セキュリティ モジュール（HSM）
Kubernetes Secret
Kubernetes の Secret リソースは、パスワード、OAuth トークン、SSH 認証鍵などの機密性の高いデータをクラスタに格納します。Secret への機密データの保存は、平文の ConfigMaps や Pod 仕様への保存よりも安全です。Secret を使用すると、機密データの使用方法を制御し、権限のないユーザーにデータが公開されるリスクを軽減できます。