このドキュメントでは、サードパーティ テナントによって配布されるカスタムアプリをホストする Google Kubernetes Engine（GKE）クラスタを構成して保護する際に活用できるコントロールについて推奨事項を示します。これは、以下の対象で構成されるブループリント ソリューションの一部です。
- 実装するコントロールのガイド（このドキュメント）。
- 次のディレクトリを含む GitHub リポジトリ。
terraform: プロジェクト レベルのインフラストラクチャとリソースの作成に使用する Terraform コードが含まれます。このコードにより、クラスタに GKE Enterprise コンポーネントもインストールされます。configsync: GKE クラスタに適用されるクラスタレベルのリソースと構成が含まれます。tenant-config-pkg: GKE クラスタで新しいテナントを構成するためのテンプレートとして使用できる kpt パッケージ。
このドキュメントは、GKE クラスタを管理するチームを対象としています。また、GKE と Kubernetes を理解していることを前提としています。
このドキュメントは、Google Cloud エンタープライズ基盤ブループリントで説明しているコントロールなどのクラウド インフラストラクチャを保護する基本的な一連のセキュリティ コントロールをすでに構成していることを前提としています。このブループリントは、既存のセキュリティ コントロールに追加のコントロールを適用して、GKE クラスタを保護する際に活用できます。
アーキテクチャ
次の図は、このブループリントを使用して作成するアーキテクチャを示しています。
上の図に示すように、このブループリントは以下のインフラストラクチャ コンポーネントを作成して構成する際に活用できます。
- Virtual Private Cloud（VPC）ネットワークとサブネット。
- 限定公開 GKE クラスタ。クラスタノードはインターネットから隔離されています。
- 2 つの GKE ノードプール。テナントアプリとリソースを排他的にホストする専用のノードプールを作成します。他のクラスタ リソースは、デフォルトのノードプールでホストされます。
- VPC ファイアウォール ルール。クラスタ内のすべてのノードに適用されるベースライン ルールを作成します。テナント ノードプール内のノードにのみ適用される追加のルールを作成します。これらのファイアウォール ルールは、テナントノードからの下り（外向き）を制限します。
- クラスタノードからインターネットへの下り（外向き）を許可する Cloud NAT。
- クラスタ内のアプリがインターネットを経由することなく Google API にアクセスできるように限定公開の Google アクセスを有効化するように構成されている Cloud DNS ルール。
- クラスタノードとアプリで使用されるサービス アカウント。
アプリケーション
次の図は、ブループリントを使用して作成および構成するクラスタレベルのリソースを示しています。
上の図に示すように、ブループリントでは、以下の対象を使用してクラスタレベルのリソースを作成および構成します。
- Git リポジトリからクラスタの構成とポリシーを同期する Config Sync。
- クラスタ内のリソースにポリシーを適用する Policy Controller。
- ネットワーク トラフィックを制御、保護する Anthos Service Mesh。
- テナントアプリとリソース専用の名前空間。
- ネットワーク ポリシーやサービス メッシュ ポリシーなど、テナント名前空間に適用されるポリシーとコントロール。
必要なセキュリティ管理について
このセクションでは、GKE クラスタを保護するためのブループリントで適用するコントロールについて説明します。
GKE クラスタのセキュリティの強化
セキュリティのベスト プラクティスに従ってクラスタを作成します。
このブループリントは、次のセキュリティ設定を実装する GKE クラスタを作成する際に活用できます。
- 承認済みネットワークを使用して限定公開 GKE クラスタを作成して、クラスタノードとコントロール プレーンのインターネットへの公開を制限する。
containerdランタイムで強化されたノードイメージを使用するシールドされたノードを使用する。- GKE Sandbox を使用して、テナント ワークロードの分離を強化する。
- アプリケーション レイヤでクラスタの Secret を暗号化する。
GKE のセキュリティ設定の詳細については、クラスタのセキュリティの強化をご覧ください。
VPC ファイアウォール ルール
仮想マシン間のトラフィックを制限する
Virtual Private Cloud（VPC）ファイアウォール ルールは、Compute Engine VM との間で許可するトラフィックを制御します。このルールを使用すると、レイヤ 4 属性に応じて VM の粒度でトラフィックをフィルタリングできます。
デフォルトの GKE クラスタのファイアウォール ルールを使用して GKE クラスタを作成します。これらのファイアウォール ルールにより、クラスタノードと GKE コントロール プレーン間の通信、およびクラスタ内のノードと Pod 間の通信が有効になります。
テナント ノードプール内のノードに追加のファイアウォール ルールを適用します。これらのファイアウォール ルールは、テナントノードからの下り（外向き）トラフィックを制限します。このアプローチでは、テナントノードの分離を強化できます。デフォルトでは、テナントノードからの下り（外向き）トラフィックはすべて拒否されます。必要な下り（外向き）は明示的に構成する必要があります。たとえば、ブループリントを使用して、テナントノードから GKE コントロール プレーンへの、および限定公開の Google アクセスを使用した Google API への外向き（下り）を許可するファイアウォール ルールを作成します。ファイアウォール ルールは、テナント ノードプールのサービス アカウントを使用するテナントノードを対象とします。
名前空間
同じポリシーを使用するリソースにラベルを付ける
名前空間を使用すると、Pod、Service、レプリケーション コントローラなど、クラスタ内の関連付けられたリソースのスコープを指定できます。名前空間を使用することによって、関連付けられたリソースの管理責任を 1 つのユニットとして委任できます。したがって、名前空間はほとんどのセキュリティ パターンに不可欠です。
名前空間は、制御プレーンを分離するための重要な機能です。ただし、ノード分離、データプレーンの分離、ネットワークの分離を行うことはできません。
一般的な方法は、個別のアプリケーションの名前空間を作成することです。たとえば、アプリケーションの UI コンポーネントに myapp-frontend という名前空間を作成できます。
このブループリントは、サードパーティ アプリをホストする専用の名前空間を作成する際に活用できます。名前空間とそのリソースは、クラスタ内のテナントとして扱われます。名前空間にポリシーとコントロールを適用して、名前空間内のリソースのスコープを制限します。
ネットワーク ポリシー
クラスタ内でのネットワーク トラフィック フローの適用
ネットワーク ポリシーは、Pod レベルのファイアウォール ルールを使用して、レイヤ 4 ネットワーク トラフィック フローを処理します。ネットワーク ポリシーのスコープは名前空間です。
ブループリントでは、サードパーティ アプリをホストするテナント名前空間にネットワーク ポリシーを適用します。デフォルトでは、ネットワーク ポリシーは名前空間内の Pod との間で送受信されるすべてのトラフィックを拒否します。必要なトラフィックは、明示的に許可リストに登録する必要があります。たとえば、ブループリントのネットワーク ポリシーは、クラスタの内部 DNS や Anthos Service Mesh コントロール プレーンなど、必要なクラスタ サービスへのトラフィックを明示的に許可します。
Config Sync
GKE クラスタへの構成の適用
Config Sync は、Git リポジトリに保存されている構成ファイルと GKE クラスタの同期を維持します。Git リポジトリは、クラスタ構成とポリシーに関する信頼できる単一の情報源として機能します。Config Sync は宣言型です。ポリシーを適用するためにクラスタの状態を継続的にチェックし、構成ファイルで宣言されている状態を適用します。これにより、構成のずれを防ぐことができます。
Config Sync を GKE クラスタにインストールします。ブループリントに関連付けられた GitHub リポジトリからクラスタの構成とポリシーを同期するように Config Sync を構成します。同期されるリソースには次のものがあります。
- クラスタレベルの Anthos Service Mesh 構成
- クラスタレベルのセキュリティ ポリシー
- テナントの名前空間レベルの構成とポリシー（ネットワーク ポリシー、サービス アカウント、RBAC ルール、Anthos Service Mesh の構成など）
Policy Controller
ポリシーの遵守の強制
GKE Enterprise Policy Controller は Kubernetes 向けの動的アドミッション コントローラです。Open Policy Agent（OPA）によって実行される CustomResourceDefinition ベース（CRD ベース）のポリシーを適用します。
アドミッション コントローラは、オブジェクトが永続化される前、かつリクエストが認証、承認された後に Kubernetes API サーバーへのリクエストをインターセプトする Kubernetes プラグインです。アドミッション コントローラを使用して、クラスタの使用方法を制限できます。
Policy Controller を GKE クラスタにインストールします。ブループリントには、クラスタの保護に役立つサンプル ポリシーが含まれています。Config Sync を使用して、ポリシーをクラスタに自動的に適用します。次のポリシーを適用します。
- Pod セキュリティの適用に役立つ選択済みのポリシー。たとえば、Pod が特権コンテナを実行するのを防止し、読み取り専用のルート ファイル システムを必要とするポリシーを適用します。
- Policy Controller テンプレート ライブラリのポリシー。たとえば、NodePort タイプのサービスを禁止するポリシーを適用します。
Anthos Service Mesh
サービス間の安全な通信の管理
Anthos Service Mesh は、Istio ベースのサービス メッシュのモニタリングと管理に役立ちます。サービス メッシュは、サービス間で管理されており、監視可能かつ安全な通信を作成する際に活用できるインフラストラクチャ レイヤです。
Anthos Service Mesh は、次の方法でサービス間の安全な通信の管理を簡素化します。
- トラフィックの認証と暗号化の管理（クラスタ内でサポートされているプロトコルと mTLS（mutual Transport Layer Communication）を使用）。Anthos Service Mesh は、通信を中断することなく、GKE Enterprise ワークロードの mTLS 鍵と証明書のプロビジョニングとローテーションを管理します。定期的に mTLS キーをローテーションすることは、攻撃を受けた場合のリスクを軽減する方法としておすすめします。
- ネットワーク上のピアの IP アドレスではなく、サービス ID に基づいてネットワーク セキュリティ ポリシーを構成。ワークロードのネットワーク ロケーションに依存しないポリシーを作成できるように、Anthos Service Mesh は、ID 対応のアクセス制御（ファイアウォール）ポリシーの構成で使用されます。このアプローチにより、サービス間通信ポリシーの設定プロセスが簡単になります。
- 特定のクライアントからのアクセスを許可するポリシーを構成。
ブループリントは、Anthos Service Mesh をクラスタにインストールするためのガイドを示します。自動サイドカー プロキシ インジェクション用にテナント名前空間を構成します。このアプローチにより、テナント名前空間のアプリがメッシュの一部になります。Config Sync を使用して Anthos Service Mesh を自動的に構成します。次の操作を行うメッシュを構成します。
- メッシュ内のサービス間に mTLS 通信を適用する。
- メッシュからの送信トラフィックを既知のホストのみに制限する。
- メッシュ内のサービス間の承認済みの通信を制限する。たとえば、テナント名前空間内のアプリは、同じ名前空間内のアプリまたは既知の外部ホストのセットとのみ通信できます。
- すべての送信トラフィックの場合は、さらにトラフィック制御を適用できるメッシュ ゲートウェイ経由でルーティングします。
Node Taints とアフィニティ
ワークロードのスケジューリングの制御
Node Taints とノード アフィニティは、Pod をクラスタノードにスケジュールする方法に影響を与える Kubernetes メカニズムです。
taint を追加したノードは Pod を排除します。Kubernetes は、Pod に taint の toleration がなければ、taint が追加されたノードに Pod をスケジュールしません。Node Taints を使用すると、特定のワークロードまたはテナントのみが使用するノードを予約できます。taint と toleration はマルチテナント クラスタでよく使用されます。詳細については、taint と toleration を使用した専用ノードのドキュメントをご覧ください。
ノード アフィニティを使用すると、Pod を特定のラベルを持つノードに制限できます。Pod にノード アフィニティの要件が存在する場合は、ノードにアフィニティの要件と一致するラベルが付加されている場合を除き、Kubernetes はノードに Pod をスケジュール設定しません。ノード アフィニティを使用すると、Pod を適切なノードにスケジュール設定できます。
Node Taints とノード アフィニティを併用すると、テナント ワークロード Pod がテナント用に予約されたノードにのみスケジュールされます。
このブループリントは、次の方法でテナントアプリのスケジュールを制御する際に活用できます。
- テナント専用の GKE ノードプールを作成する。プール内の各ノードには、テナント名に関連する taint があります。
- テナント名前空間をターゲットとする Pod に適切な toleration とノード アフィニティを自動的に適用する。toleration とアフィニティは、PolicyController のミューテーションを使用して適用します。
最小権限
クラスタ リソースとプロジェクト リソースへのアクセスを制限する
セキュリティのベスト プラクティスは、Google Cloud プロジェクトと GKE クラスタなどのリソースに対して最小権限の原則を採用することです。これにより、クラスタ内で実行されるアプリと、クラスタを使用するデベロッパーやオペレーターには、必要最小限の権限セットのみが付与されます。
このブループリントは、次の方法で最小権限のサービス アカウントを使用する際に活用できます。
- 各 GKE ノードプールは独自のサービス アカウントを受け取ります。たとえば、テナント ノードプール内のノードは、それらのノード専用のサービス アカウントを使用します。ノードサービス アカウントは、必要最小限の権限で構成されます。
- クラスタは Workload Identity を使用して、Kubernetes サービス アカウントを Google サービス アカウントに関連付けます。これにより、サービス アカウント キーをダウンロードして保存することなく、必要な Google API への制限付きアクセス権をテナントアプリに付与できます。たとえば、Cloud Storage バケットからデータを読み取る権限をサービス アカウントに付与できます。
このブループリントは、次の方法でクラスタ リソースへのアクセスを制限する際に活用できます。
- アプリを管理するための権限が限定された Kubernetes RBAC ロールのサンプルを作成します。このロールは、テナント名前空間でアプリを操作するユーザーとグループに付与できます。これにより、これらのユーザーには、テナント名前空間内のアプリリソースを変更する権限のみが付与されます。クラスタレベルのリソースや、Anthos Service Mesh ポリシーなどの機密性の高いセキュリティ設定を変更する権限は付与されません。
まとめ
このドキュメントで説明しているアーキテクチャを実装する方法は次のとおりです。
- ブループリントをエンタープライズ基盤ブループリントと併用してデプロイするか、使用せずにデプロイするかを決定します。エンタープライズ基盤ブループリントをデプロイしない場合は、同様のセキュリティ ベースラインを環境に設定するようにしてください。
- ブループリントの README を確認し、すべての前提条件を満たしていることを確認します。
- テスト環境に、このアーキテクチャのインスタンスを 1 つデプロイします。テストプロセスの一環として、次のことを行います。
- ブループリントを本番環境にデプロイする。
- クラスタにテナントを追加する。
次のステップ
- Google Cloud エンタープライズ基盤ブループリントを読む
- GKE 強化ガイドを読む
GKE で Anthos Service Mesh Egress ゲートウェイを使用するためのベスト プラクティスについて確認する