Anthos のセキュリティ設計図: ポリシーからの逸脱の監査とモニタリング

このドキュメントでは、Anthos クラスタに対する監査とモニタリングを実行し、セキュリティに関するベスト プラクティスおよびクラスタに接続したポリシーからの逸脱の有無を判断する方法について説明します。ポリシーに対する監査とモニタリングを実行する方法および理由の概要、さらにこのタスクに使用する Google Cloud コントロールについて説明します。

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

概要

クラスタには、アセットへのアクセスを保護できるようにするポリシーがあります。これらのポリシーからの逸脱に対して監査とモニタリングを実行することで、セキュリティを強化できます。監査とモニタリングでは、クラスタの現在のステータスを分析できますが、ポリシーを回避するアクションを阻止することはできません。変更を防ぐには、ポリシーを適用するための手順も実行する必要があります。

モニタリングは監査と類似していますが、目的がやや異なります。一般的なモニタリング ソリューションは、指標を収集する方法、システムとアプリのステータスを表示するダッシュボード、異常が検出されたときにアラートを送信する方法で構成されます。対照的に、監査はシステムのステータスを検証するために使用します。通常は、システムが満たす必要があるものとして定義した一連のポリシーに照らして検証を行います。

監査とモニタリングを行うには、次の要件を考慮する必要があります。

  • 実施している適用管理と、ポリシーからの逸脱を監査またはモニタリングする方法。
  • 統合されたモニタリング ソリューションと分離されたソリューションのどちらを必要とするか。

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

このセクションでは、以下のことを行うために必要な制御について説明します。

  • ポリシーの適用ガイドに記載されているように、ポリシーの適用を補完する監査を実装する。

  • Anthos GKE クラスタをデプロイする場所に関係なく機能するモニタリング ソリューションを実装する。

Namespace

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

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

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

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

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、リソース割り当て、Namespace、プラットフォーム レベルでのインフラストラクチャのデプロイなどのアクセス制御ポリシーを管理できます。Anthos Config Management は宣言型です。クラスタの状態を継続的にチェックし、ポリシーを適用するために構成で宣言された状態を適用します。

Anthos Policy Controller

ポリシーの遵守の強制

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

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

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

次の図は、ポリシー コントローラが OPA Constraint Framework を使用してポリシーを定義、適用する方法を示しています。

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

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

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

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

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

ポリシー コントローラを使用して、定義したポリシーを適用する方法の詳細については、Anthos Config Management ポリシー コントローラをご覧ください。

Kubernetes Engine Operations

GKE クラスタのモニタリング

Kubernetes Engine Operations は、GKE クラスタをモニタリングするように設計されています。Cloud Monitoring サービスと Cloud Logging サービスをまとめて管理し、GKE クラスタ用にカスタマイズされた Kubernetes Engine Operations ダッシュボードを備えています。Kubernetes Engine Operations には、クラスタ、ノード、Pod、コンテナなどのリソースを表す一連の GKE のモニタリング対象リソースが用意されています。GKEGKE On-Prem クラスタでは Kubernetes Engine Operations を無効にすることはできますが、これらのプロダクトでは有効にしておくことをおすすめします。

Security Health Analytics

脆弱性の特定

Security Health Analytics では、Google Cloud リソースの潜在的な構成ミスやコンプライアンス違反を特定し、適切な対処方法を提案することによってインシデントの発生を防止できるようにします。Security Health Analytics スキャナは、Security Command Center で利用可能な脆弱性検出のタイプを生成します。コンテナ スキャナの検出結果は GKE コンテナの構成に関連し、CONTAINER_SCANNER スキャナタイプに属します。

Security Command Center と Pub/Sub の統合

通知アプリを使用して、Security Command Center から検出結果に関するアラートを受け取ることができます。アプリは通知 Pub/Sub トピックに登録し、構成されたチャネル(メールや SMS など)に通知を送信します。

Cloud Asset Inventory

Google Cloud リソースのモニタリング

Cloud Asset Inventory を使用すると、登録しているリソースやポリシーの変更をリアルタイムの通知によってモニタリングできます。組織、フォルダ、プロジェクト、または指定したその他のリソース内でサポートされているリソースタイプポリシータイプの変更をモニタリングできます。登録を設定するには、フィードを作成します。サポートされているアセットタイプには、GKE リソースタイプと Cloud IAM ポリシータイプがあります。

ファイアウォール ルールや IAM ポリシーの変更など、セキュリティが重視されるリソースをモニタリングできます。これらのリソースの変更が行われると、直ちに Pub/Sub から通知が送信され、必要に応じて迅速に対処できます。

リアルタイム通知は、既存のワークロードに接続します。この機能を使用すると、変更が検出された後にリソースの変更を元に戻すために Cloud Functions の関数を作成するなどのアクションを統合できます。

Cloud Audit Logs を使用したアラート

GKE クラスタは Kubernetes Audit LoggingCloud Audit LogsCloud Logging に統合します。Kubernetes Engine Operations を使用して、ログエントリに基づいて指標を設定できます。その後、ログベースの指標を使用してアラート ポリシーを設定できます。

アラート ポリシーは通知チャネルを指定します。通知チャネルによって、アラート ポリシーがトリガーされたことを通知する方法を指定できます。通知ハンドラを設定するには、Cloud Run または Cloud Functions を使用して、対応措置(変更を元に戻す、メールで通知するなど)を講じます。

まとめ

コントロールを統合するには、監査とモニタリングに関するニーズを決定します。次に、このガイドで説明したコントロールの範囲と、コントロールを構成する必要があるステージを、次の手順で説明するようにマッピングします。

  1. クラスタの構成を開始する前に、ハイブリッドおよびマルチクラウドのモニタリングとロギングのパターンを参照して、必要な分離レベルを決定してください。

  2. クラスタを作成します。該当するクラスタ強化ガイド(GKE または GKE On-Prem)のガイダンスに従います。クラスタを作成する場合は、強化ガイドに従って --enable-network-policy フラグを使用してください。その際、ネットワーク ポリシーが必要です。この手順により、クラスタ内の Pod 間を通過するトラフィックを制限するファイアウォール ルールを後で実装できます。

  3. Pod に必要な Namespace とラベルを定義します。これにより、ポリシーと Kubernetes サービス アカウントを操作できる名前スコープが指定されます。

  4. Anthos Config Management を使用してポリシー コントローラをインストールします。

    ポリシーの適用ガイドに記載されているガイダンスに従ってください。

  5. 要件を満たすように Kubernetes Engine Operations を構成します。

  6. Kubernetes Engine Operations のアラート ポリシー、通知、ハンドラを構成します。

  7. Cloud Asset Inventory からのリアルタイム通知を構成します。

  8. Security Health Analytics スキャンで生成されたコンテナの検出結果を定期的に確認するプロセスを設定します。