サードパーティ テナント用の GKE クラスタの準備

このドキュメントでは、サードパーティ テナントによって配布されるカスタムアプリをホストする Google Kubernetes Engine(GKE)クラスタを構成して保護する際に活用できるコントロールについて推奨事項を示します。これは、以下の対象で構成されるブループリント ソリューションの一部です。

  • 実装するコントロールのガイド(このドキュメント)。
  • 次のディレクトリを含む GitHub リポジトリ
    • terraform: プロジェクト レベルのインフラストラクチャとリソースの作成に使用する Terraform コードが含まれています。このコードは、Anthos コンポーネントをクラスタにもインストールします。
    • configsync: GKE クラスタに適用されるクラスタレベルのリソースと構成が含まれています。
    • tenant-config-pkg: kpt パッケージ。これは、GKE クラスタに新しいテナントを構成するためのテンプレートとして使用できます。

このドキュメントは、GKE クラスタを管理するチームを対象としています。このドキュメントは、GKE と Kubernetes に精通していることを前提としています。

このドキュメントは、Google Cloud セキュリティ基盤ガイドで説明しているコントロールなどのクラウド インフラストラクチャを保護する基本的な一連のセキュリティ コントロールをすでに構成していることを前提としています。このブループリントは、既存のセキュリティ制御にセキュリティ管理機能を追加して、GKE クラスタを保護する際に活用できます。

アーキテクチャ

次の図は、このブループリントを使用して作成するアーキテクチャを示しています。

ブループリントのインフラストラクチャ コンポーネント。

上の図に示すように、ブループリントは以下のインフラストラクチャ コンポーネントを作成して構成する際に活用できます。

  • Virtual Private Cloud(VPC)ネットワークとサブネット。
  • 限定公開 GKE クラスタ。クラスタノードがインターネットから隔離されている。
  • 2 つの GKE ノードプール。テナントのアプリとリソースのみをホストする専用ノードプールを作成します。その他のクラスタ リソースは、デフォルトのノードプールにホストされます。
  • VPC ファイアウォール ルール。クラスタ内のすべてのノードに適用されるベースライン ルールを作成します。テナントのノードプール内のノードにのみ適用される追加のルールを作成します。これらのファイアウォール ルールにより、単一テナントノードからの下り(外向き)が制限されます。
  • クラスタノードからインターネットへの下り(外向き)を許可する Cloud NAT
  • クラスタ内のアプリがインターネットを経由することなく Google API にアクセスできるように限定公開の Google アクセスを有効化するように構成されている Cloud DNS ルール。
  • クラスタノードとアプリで使用されるサービス アカウント

アプリケーション

次の図は、ブループリントを使用して作成および構成したクラスタレベルのリソースを示しています。

クラスタレベルのリソース。

上の図に示すように、ブループリントでは、以下の対象を使用してクラスタレベルのリソースを作成および構成します。

  • Anthos Config Management Config Sync。Git リポジトリからクラスタの構成とポリシーを同期できます。
  • クラスタ内のリソースにポリシーを適用するには、Anthos Config Management Policy Controller を使用します。
  • Anthos Service Mesh。ネットワーク トラフィックを制御、保護します。
  • テナントアプリとリソース専用の Namespace。
  • テナント Namespace に適用されるポリシーと制御(ネットワーク ポリシーとサービス メッシュ ポリシーを含む)。

必要なセキュリティ管理について

このセクションでは、GKE クラスタを保護するためにブループリントで適用するコントロールについて説明します。

GKE クラスタのセキュリティ強化

セキュリティのベスト プラクティスに従ってクラスタを作成します。

このブループリントは、次のセキュリティ設定を実装する GKE クラスタを作成する際に活用できます。

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 は、GKE クラスタを Git リポジトリに保存されている構成ファイルと同期させます。Git リポジトリは、クラスタ構成とポリシーに関する信頼できる唯一の情報源として機能します。Config Sync は宣言型です。クラスタの状態を継続的にチェックし、ポリシーを適用するために構成ファイルで宣言された状態を適用します。これにより、構成のずれを防ぐことができます。

Config Sync を GKE クラスタにインストールします。ブループリントに関連する GitHub リポジトリからクラスタ構成とポリシーを同期するように Config Sync を構成します。同期されるリソースは次のとおりです。

  • クラスタレベルの Anthos Service Mesh 構成
  • クラスタレベルのセキュリティ ポリシー
  • テナントの名前空間レベルの構成とポリシー(ネットワーク ポリシー、サービス アカウント、RBAC ルール、Anthos Service Mesh の構成など)

Policy Controller

ポリシーの遵守の強制

Anthos Policy Controller は Kubernetes 向けの動的アドミッション コントローラであり、Open Policy Agent(OPA)によって実行される CustomResourceDefinition ベース(CRD ベース)のポリシーを適用します。

アドミッション コントローラは、オブジェクトが永続化される前、かつリクエストが認証、承認された後に Kubernetes API サーバーへのリクエストをインターセプトする Kubernetes プラグインです。アドミッション コントローラを使用して、クラスタの使用方法を制限できます。

GKE クラスタに Policy Controller をインストールします。このブループリントには、クラスタを保護するためのポリシーの例が含まれています。Config Sync を使用して、クラスタにポリシーを自動的に適用します。次のポリシーを適用します。

Anthos Service Mesh

サービス間の安全な通信の管理

Anthos Service Mesh は、Istio ベースのサービス メッシュのモニタリングと管理に役立ちます。サービス メッシュは、サービス間で管理されており、監視可能かつ安全な通信を作成する際に活用できるインフラストラクチャ レイヤです。

Anthos Service Mesh は、次の方法でサービス間の安全な通信の管理を簡素化します。

  • トラフィックの認証と暗号化の管理(クラスタ内でサポートされているプロトコルmTLS(mutual Transport Layer Communication)を使用)。Anthos Service Mesh は、通信を中断することなく、Anthos ワークロードの mTLS 鍵と証明書のプロビジョニングとローテーションを管理します。定期的に mTLS キーをローテーションすることは、攻撃を受けた場合のリスクを軽減するおすすめの方法です。
  • ネットワーク上のピアの IP アドレスではなく、サービス ID に基づいてネットワーク セキュリティ ポリシーを構成。ワークロードのネットワーク ロケーションに依存しないセキュリティポリシーを作成できるように、Anthos Service Mesh は、ID 対応のアクセス制御(ファイアウォール)ポリシーの構成で使用されます。このアプローチにより、サービス間通信ポリシーの設定プロセスが簡素化されます。
  • 特定のクライアントからのアクセスを許可するポリシーを構成。

ブループリントは、クラスタに Anthos Service Mesh をインストールする方法について説明します。自動サイドカー プロキシ インジェクションのテナント名前空間を構成します。このアプローチにより、テナント Namespace 内のアプリはメッシュの一部になります。Anthos Service Mesh は、Config Sync を使用して自動的に構成します。次のことを行うようにメッシュを構成します。

  • メッシュ内のサービス間の mTLS 通信を適用します。
  • メッシュからの送信トラフィックを既知のホストのみに制限します。
  • メッシュ内のサービス間の承認済み通信を制限します。たとえば、テナント Namespace 内のアプリは、同じ Namespace 内のアプリまたは既知の外部ホストとのみ通信できます。
  • すべての送信トラフィックの場合は、さらにトラフィック制御を適用できるメッシュ ゲートウェイ経由でルーティングします。

ノード taint とアフィニティ

ワークロードのスケジューリングの制御

Node Taintsノード アフィニティは、Pod をクラスタノードにスケジュールする方法を制御する Kubernetes メカニズムです。

taint を追加したノードは Pod を排除します。Kubernetes は、Pod に taint の容認がなければ、taint を追加↓ノードに Pod をスケジュールしません。Node Taints を使用すると、特定のワークロードまたはテナントのみが使用するノードを予約できます。taint と容認機能はマルチテナント クラスタでよく使用されます。詳細については、taint と容認機能を使用した専用ノードのドキュメントをご覧ください。

ノード アフィニティを使用すると、Pod を特定のラベルを持つノードに制限できます。Pod にノード アフィニティの要件が存在する場合は、ノードにアフィニティの要件と一致するラベルが付加されている場合を除き、Kubernetes はノードに Pod をスケジュール設定しません。ノード アフィニティを使用すると、Pod を適切なノードにスケジュール設定できます。

ノード taint とノード アフィニティを組み合わせて使用すると、テナント ワークロード Pod がテナント専用に予約されたノードにのみスケジュールされるようになります。

ブループリントは、次の方法でテナントアプリのスケジューリングを制御できます。

  • テナント専用の GKE ノードプールを作成します。 プール内の各ノードにはテナント名に関連する taint があります。
  • テナント Namespace をターゲットとする Pod に適切な容認機能とノード アフィニティを自動的に適用する。容認とアフィニティは、PolicyController mutations を使用して適用します。

最小限の権限

クラスタ リソースとプロジェクト リソースへのアクセスを制限する

セキュリティの観点から、Google Cloud プロジェクトと GKE クラスタなどのリソースには最小権限の原則を採用することをおすすめします。このようにして、クラスタ内で実行されるアプリと、クラスタを使用するデベロッパーとオペレーターには、必要最小限の権限のみが与えられます。

このブループリントは、最小権限のサービス アカウントを次の方法で使用するのに役立ちます。

  • 各 GKE ノードプールは独自のサービス アカウントを受け取ります。たとえば、テナントノードプール内のノードは、それらのノード専用のサービス アカウントを使用します。ノードサービス アカウントには、最低限必要な権限が構成されます。
  • クラスタは Workload Identity を使用して、Kubernetes サービス アカウントを Google サービス アカウントに関連付けます。この方法では、サービス アカウントキーをダウンロードして保存しなくても、必要な Google API への限定的なアクセス権がテナントアプリに付与できます。たとえば、Cloud Storage バケットからデータを読み取る権限をサービス アカウントに付与できます。

このブループリントは、次の方法でクラスタ リソースへのアクセスを制限するのに役立ちます。

  • アプリを管理する権限が制限されたサンプルの Kubernetes RBAC ロールを作成します。テナントの名前空間でアプリを操作するユーザーとグループに、このロールを付与できます。このようにすると、これらのユーザーにはテナント Namespace 内のアプリリソースを変更する権限のみが付与されます。クラスタレベルのリソースや、Anthos Service Mesh ポリシーなどの機密性の高いセキュリティ設定を変更する権限はありません。

まとめ

このドキュメントで説明しているアーキテクチャを実装する方法は次のとおりです。

  1. ブループリントをセキュリティ基盤のブループリントと併用してデプロイするか、使用せずにデプロイするかを決定します。セキュリティ基盤のブループリントをデプロイしない場合は、環境に同様のセキュリティ ベースラインを設定するようにしてください。
  2. ブループリントの Readme を確認し、すべての前提条件を満たしていることを確認します。
  3. テスト環境で、このアーキテクチャのインスタンスを 1 つデプロイします。テストプロセスの一環として、次のことを行います。
    1. サンプルのテナント サービスをデプロイし、クラスタの構成を確認する
    2. クラスタに別のテナントを追加する
  4. ブループリントを本番環境にデプロイする。
  5. クラスタにテナントを追加する。

次のステップ