Anthos のセキュリティ設計図: ポリシーの適用

このドキュメントでは、Anthos クラスタにセキュリティ ポリシーを適用する方法について説明します。ポリシーを適用する方法とその理由、このタスクに使用する Google Cloud の制御機能について説明します。

このドキュメントは、Anthos の使用に関する規範的なガイダンスを示す一連のセキュリティ設計図の一部です。

概要

クラスタにポリシーを適用して、セキュリティとコンプライアンスの要件を満たしていることを確認します。ポリシーを適用したら、ポリシーが適用されていることと、指定したポリシー構成に Anthos クラスタの設定が準拠していることを確認する必要があります。

ポリシーの適用は、クラスタの監査を補完します。監査では、クラスタの過去と現在のステータスを確認できますが、ポリシーを回避するアクションを防ぐことはできません。ポリシーの適用は予防的な対策といえます。要件を満たすには、クラスタレベルと名前空間レベルでポリシーを適用する必要があります。

次の要件を適用する方法を検討する必要があります。

  • リソースの使用量を制限する。
  • クラスタ内のネットワーク トラフィックを制限する。
  • Pod を実行できる機能を制限する。
  • カスタム ポリシー(必要なラベルの適用など)を定義する。

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

このセクションでは、セキュリティとコンプライアンスの要件を満たすために必要なポリシーを適用する際に必要な制御について説明します。

名前空間

同じポリシーを使用するリソースにラベルを付ける

名前空間を使用すると、Pod、Service、レプリケーション コントローラなど、クラスタ内の関連付けられたリソースのスコープを指定できます。名前空間を使用することによって、関連付けられたリソースの管理責任を 1 つのユニットとして委任できます。したがって、名前空間はほとんどのセキュリティ パターンに不可欠です。

名前空間は、制御プレーンを分離するための重要な機能です。ただし、ノード分離、データプレーンの分離、ネットワークの分離を行うことはできません。

一般的な方法は、個別のアプリケーションの名前空間を作成することです。たとえば、アプリケーションの UI コンポーネントに myapp-frontend という名前空間を作成できます。

リソースの割り当て

リソースの使用量の制御

GKE は、複数のチームが管理する同じクラスタ内で複数のアプリケーションを実行できるように設計されています。クラスタ内のリソース使用量を管理するチームが 1 つもない場合、クラスタ内で実行されているアプリケーションが必要以上のリソースを消費する可能性があります。この状況を防ぐには、管理者が名前空間で定義されたリソースの総消費量を制限するため、リソース割り当てを構成する必要があります。

Anthos Config Management

Anthos クラスタへの構成の適用

Anthos クラスタを管理する場合のおすすめの方法は、Anthos Config Management を使用することです。これにより、登録済みのクラスタが常に構成と同期されます。コンフィグリポジトリに保存されている YAML または JSON ファイルであり、これには kubectl apply コマンドを使用して手動でクラスタに適用できるものと同じタイプの構成情報が含まれています。Anthos Config Management を使用すると、policy-as-code の手法を採用することにより、ポリシーの場合と同様にポリシーとインフラストラクチャのデプロイを管理できます。

Anthos Config Management は、宣言されたポリシーの唯一の認証ソースとして機能する Git リポジトリと組み合わせて使用します。Anthos Config Management によって、RBAC、リソース割り当て、名前空間、プラットフォーム レベルでのインフラストラクチャのデプロイなどのアクセス制御ポリシーを管理できます。Anthos Config Management は宣言型です。クラスタの状態を継続的にチェックし、ポリシーを適用するために構成で宣言された状態を適用します。

ネットワーク ポリシー

クラスタ内でのネットワーク トラフィック フローの適用

ネットワーク ポリシーは、Pod レベルのファイアウォール ルールを使用して、レイヤ 4 ネットワーク トラフィック フローを処理します。ネットワーク ポリシーのスコープは名前空間です。

デフォルトでは、その名前空間に対してネットワーク ポリシーが有効になっていても、クラスタ内の Pod へのアクセスは制限されません。少なくとも 1 つの NetworkPolicy オブジェクトが Pod を選択すると、ルールが適用されます。

ベスト プラクティスは、最小権限のアプローチの採用です。ネットワーク ポリシーを実装する場合は、すべての Pod に一致するように、名前空間にデフォルトの deny-all ルールを作成することをおすすめします。これにより、名前空間でアクセスがブロックされます(つまり、フェール クローズシステムとして機能します)。ネットワーク トラフィック フローを許可するには、名前空間ごとにネットワーク ポリシーを明示的に設定する必要があります。

次の図では、名前空間ごとにネットワーク ポリシーを構成し、名前空間間のトラフィック フローを管理しています。

ネットワーク ポリシーを使用して名前空間間のトラフィック フローを管理する。

この例では、トラフィックは transactions という名前空間と shopfront という名前空間の間で双方向に送信されています。ただし、shopfront という名前空間からロギングアプリにのみトラフィック フローが許可されています。

Anthos Config Management を使用して適用可能な NetworkPolicy コンフィグの例については、Kubernetes オブジェクトの構成で NetworkPolicy コンフィグのセクションをご覧ください。

Anthos Policy Controller

ポリシーの遵守の強制

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

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

ポリシー コントローラを使用するには、制約テンプレートで一連の制約を宣言します。制約テンプレートがクラスタにデプロイされたら、制約テンプレートによって定義される個別の制約 CRD を作成できます。

次の図に、Policy Controller が OPA Constraint Framework を使用してポリシーを定義、適用する方法を示します。

OPA Constraint Framework はリクエストを受信し、他のリソースへのアクセスに関するポリシーを適用します。

この図は次のことを示しています。

  1. 制約は制約テンプレートから作成されます。
  2. クラスタでポリシーを有効にするには、制約を適用します。
  3. リクエストを受信するとアドミッションの審査がトリガーされ、許可または拒否の決定が行われます。
  4. 継続的な監査では、クラスタ上のすべてのアクティブなオブジェクトがポリシーに基づいて評価されます。

Policy Controller を使用すると、ラベルの適用などのカスタム ポリシーを適用できます。Policy Controller では、PodSecurityPolicy で適用できる制約の大半を適用できますが、通常は、次のような理由で運用上のオーバーヘッドを削減することが必要となります。

  • Policy Controller には、制約テンプレートを含むデフォルトのテンプレート ライブラリが含まれています。つまり、PodSecurityPolicy のように、一般的なケースを対象とする独自のポリシーを作成する必要はありません。
  • PodSecurityPolicy を使用する場合とは異なり、RoleBinding を管理する必要はありません。
  • ポリシー コントローラはドライラン モードをサポートしているため、制約を適用する前にその効果を検証できます。
  • ポリシーのスコープを名前空間に設定することで、より制限の厳しいポリシーを段階的に実行できます。これは、予期しない影響が生じる可能性があるロールアウト ポリシーの公開を管理するカナリア リリース戦略と類似しています。たとえば、Pod からボリュームへのアクセスを制限していても、その Pod が対象ボリュームへのアクセス権を付与されている必要があることがロールアウトの段階で判明することがあります。
  • Policy Controller は、カスタム制約か、Gatekeeper リポジトリで定義された PodSecurityPolicy の制約かにかかわらず、ポリシーを適用する 1 つの方法として使用できます。

Policy Controller を使用して、定義したポリシーを適用する方法については、Anthos Config Management Policy Controller をご覧ください。

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 対応のアクセス制御(ファイアウォール)ポリシーの構成で使用されます。これにより、サービス間の通信を簡単に設定できます。
  • 特定のクライアントからのアクセスを許可するポリシーを構成。
  • Identity-Aware Proxy またはカスタム ポリシー エンジンを使用してユーザー認証を管理。これにより、ユーザー ID とリクエストのコンテキストを確認して、ユーザーにアクセスを許可するかどうかを判断し、Anthos GKE クラスタにデプロイしたアプリケーションへのアクセスを制御できます。

サービス間の安全な通信を管理するだけでなく、構成可能な時間枠ごとに 1 回だけ成功ログを記録することで、アクセスログのノイズを軽減できます。セキュリティ ポリシーで拒否されたリクエストや、エラーになったリクエストは常にログに記録されます。アクセスログと指標は、Google Cloud のオペレーション スイートで利用できます。

Anthos Service Mesh のセキュリティ機能ついては、Anthos Service Mesh のセキュリティの概要をご覧ください。

まとめ

ここで説明してきた制御は、Anthos GKE と Anthos GKE On-Prem の両方に使用できます。

制御を統合するには、次の手順で説明するように、このガイドで説明した制御の範囲と、制御を構成する必要があるステージをマッピングします。

  1. 該当するクラスタ強化ガイド(GKE または Anthos GKE On-Prem)のガイダンスに従ってクラスタを作成します。クラスタを作成する際は、強化ガイドに従って --enable-network-policy フラグを使用するようにしてください。ネットワーク ポリシーは必須です。この手順により、クラスタ内の Pod 間を通過するトラフィックを制限するファイアウォール ルールを後で実装できます。
  2. Pod に必要な 名前空間とラベルを定義します。これにより、ポリシーや Kubernetes サービス アカウントを操作できる名前スコープが提供されます。
  3. Anthos Config Management を使用して Policy Controller をインストールします。
  4. Anthos Config Management を使用してネットワーク ポリシーを適用します。
  5. ビルド済みの Policy Controller の制約テンプレートを収集し、制約を定義してテンプレートをリソースにマッピングします。
  6. Anthos Config Management を使用して制約テンプレートと制約を適用します。

アプリケーション レイヤ(レイヤ 7)に重点を置いた追加の制御機能を適用します。次のように Anthos Service Mesh を使用して、さらにポリシーを適用します。

  • クラスタの作成時に Istio ポリシーの適用を有効に場合は、ここで有効にします。
  • アプリケーション レイヤで適用するポリシーを定義します。ポリシーは YAML として記述します。
  • Anthos Config Management を使用して、ポリシーを適用します。