Policy Controller で Kubernetes のデプロイを保護

※この投稿は米国時間 2020 年 12 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

11 月、Kubernetes プロジェクトは、すべての Kubernetes 管理者およびユーザーが知っておくべき脆弱性を公開しました。この脆弱性（CVE-2020-8554）は、「中間者」として機能するためにセンシティブ データを傍受できるオブジェクトの作成を許可するデフォルトの権限に起因しています。Anthos や Kubernetes Engine（GKE）などの Google Cloud マネージド ソリューションを使用している場合は、この脆弱性を簡単かつ効果的に軽減できます。本ブログではその方法をご紹介します。

まず、この脆弱性について説明します。

影響を受けるユーザー: CVE-2020-8554 は、すべてのマルチテナント Kubernetes クラスタに影響します。Kubernetes クラスタのマルチテナンシーは、相互に分離する必要のある複数のユーザーが使用する単一のクラスタとして定義されます。

想定されること: この脆弱性だけでは、攻撃者に Kubernetes Service を作成する権限は付与されません。ただし、タイプが LoadBalancer または ClusterIP の Kubernetes Service を作成する権限を取得した攻撃者が、クラスタ内の他の Pod から送信されたネットワーク トラフィックを傍受できるようになる可能性があります。

この脆弱性に対処するには、Policy Controller か Open Policy Agent Gatekeeper（OPA）を使用して、この問題を緩和するための制約を実装します。このブログの残りの部分では、Anthos Config Management（ACM）の Policy Controller コンポーネントの機能を使用してこれを行う方法を説明します。

Policy Controller を使用して影響を緩和する

OPA Gatekeeper を持つ Kubernetes でこの問題を緩和するポリシーを作成する方法はいくつかあります。CVE に記載されている例では、許可された ExternalIP オブジェクトの IP アドレスのリストを使用して、この範囲外の IP アドレスを使用しようとするリクエストを拒否しています。

ここでは、同一の ACM git リポジトリと同期された 3 つの Anthos クラスタを用いてこの例を説明します。次のスクリーンショットでは、cluster-1、cluster-2、cluster-3 のクラスタ構成が ACM によってメインブランチと同期されており、最新の commit から pull されています。ACM が複数のクラスタにポリシーを適用する方法の詳細については、ACM のドキュメントをご覧ください。

各クラスタにドリルダウンすると、リポジトリとクラスタの ACM 構成に関する詳細情報が表示されます（これには、git リポジトリの URL の例が含まれます）。

Policy Controller の制約は、制約テンプレートを使用して適用されます。Policy Controller には、Google により頻繁に追加および更新される、堅牢なデフォルトの制約テンプレート セットが用意されています。この例では、OPA Gatekeeper Project により管理されている別のアップストリーム リポジトリの例を使用しています。Google Cloud は、Anthos Config Management の次の 1.6.1 リリースにて、このテンプレートの公式にサポートされたバージョンを Policy Controller ライブラリに追加することを予定していますが、このテンプレートは以前のバージョンを実行しているクラスタに直接適用できます。今回使用する制約テンプレートには、Kubernetes の ExternalIP オブジェクトに使用できる許可された IP アドレスのリストを採用しています。このリストに含まれるアドレスの一例としては「203.0.113.0」などがあります。

制約ファイルとテンプレート ファイルは、リポジトリの新しいブランチに対して commit されます。変更がレビューされ、ACM リポジトリのメインブランチにマージされると、すべてのクラスタが新しいポリシーで更新されます。

作成されたファイルを使用して、GitHub の通常の pull リクエスト プロセスを実行し、commit をマージします。

リクエストを承認してマージすると、新しいポリシーが ACM リポジトリに追加されます。各クラスタは、ACM リポジトリに対する変更を継続的にチェックします。新しい更新が検出された場合、ACM がその変更を自動的に適用し、ブレの発生を防止します。

数秒以内に、各クラスタは新しいポリシーを含む最新の commit と同期します。

各クラスタは、ACM リポジトリの最新の commit と同期することで、新しいポリシー制約を統合しています。この例では、これは「e84416」で始まる git commit ID になります。次に、このポリシーをテストします。

適用した制約で許可されたアドレスの範囲外の ExternalIP を使用して、Anthos クラスタの 1 つに Service を作成することを試みます。このテストでは、ExternalIP 値が「1.1.1.1」の Service の作成を試みます。

この Service を作成しようとすると、Service が実際に作成される前に Policy Controller の制約により検証されます。そして、Policy Controller で先ほど設定した制約に違反するため、この Service の作成は拒否されます。

行動と次のステップ

すべての Kubernetes クラスタは、CVE-2020-8554 に対する脆弱性を有する可能性があります。Policy Controller や GKE の OPA Gatekeeper を利用すれば、この脆弱性を大規模かつ効果的に軽減できます。Policy Controller のようなアドミッション コントローラを使用することは、安全な Kubernetes のデプロイにおける基本的な設計要素になります。その他のセキュリティに関するベスト プラクティスについては、Google Cloud Security Command Center をご覧ください。

CVE-2020-8554 に対する Google Cloud の対応の詳細については、GKE、Anthos オンプレミス、Anthos on AWS のセキュリティに関する情報をご覧ください。

-Google Cloud スペシャリスト カスタマー エンジニア Jamie Duncan

-Google Cloud プロダクト マネージャー John Murray