ブログ

Sysdig Kubernetes Policy Advisorを用いて本番環境でPod Security Policiesを使用する

Sysdig Kubernetes Policy Advisorを用いて本番環境でPod Security Policiesを使用する

本文の内容は、2019年11月12日にSysdigのJorge Salameroが投稿したブログ(https://sysdig.com/blog/psp-in-production/)を元に日本語に翻訳・再構成した内容となっております。

Sysdig Secure 3.0は、Kubernetes Policy Advisorを導入して、Pod Security Policies(PSP)を使用したKubernetesネイティブな防止機能を提供します。この機能により、PSPの生成が自動化され、デプロイメント前に検証されるため、適用時にアプリケーションが破損することはありません。これにより、ユーザーは本番環境でPodセキュリティポリシーを迅速かつ簡単に採用できます。PSPはKubernetesのネイティブコントロールメカニズムも提供し、ホスト上のすべてのアクションをインターセプトする必要があるエージェント方式とは異なり、パフォーマンスに影響を与えることなく脅威を防ぎます。

q01.png

Kubernetes Pod Security Policyとは?

Kubernetes Pod Security Policiesは、Podが適切な特権でのみ実行され、適切なリソースにのみアクセスできることを保証するフレームワークを提供しています。Kubernetesクラスターを運用するセキュリティチームとDevOpsチームは、それらを活用してPodの作成をコントロールし、特定のユーザー、グループ、またはアプリケーションが利用できる機能を制限できます。

Kubernetesのアクセス許可(RBAC)は、PSPをユーザーまたはサービスが持つロールを介してリンクするために使用されます。これらのユーザーまたはサービスがPodをデプロイしようとすると、PSPはPSPで定義されたポリシーに対してPodセキュリティ構成を評価するゲートキーパーとして機能します。

q02.png

最小特権ポッド許可モデル:PSPの使用例

ユーザーまたはサービスがKubernetes Podを作成できる場合、サービスは、特権コンテナの実行、ノードリソースの使用など、dockerコマンドでできることをすべて実行できます。これは、通常のユーザーまたは実行中のPodがこれを悪用して、ルートとしてKubernetesノードに到達できることを意味します。

最小特権とは、ユーザー、アカウント、およびコンピューティングプロセスのアクセス権を、通常の正当なアクティビティの実行に絶対に必要なリソースのみに制限するという概念と実践です。

PSPは、コンプライアンス認定を取得する組織にとって重要です。 PCI、SOC2、またはHIPPAなどの規制順守規格にはすべて、最小特権アクセスへの参照が含まれています。 以下に例を示します。

PCIセクション7 -ジョブを実行するために必要な最小限の特権への特権ユーザーIDへのアクセスの制限。

Pod Security Policyを使用すると、Podの動作を制限してセキュリティを向上させることができます。 例えば:

  • 特権ポッドが立ち上がるのを防ぎ、特権エスカレーションを制御します。
  • Podがアクセスできるホスト namespace、ネットワーク、およびファイルシステムへのアクセスを制限します。
  • Podを実行できるユーザー/グループを制限します。
  • Podがアクセスできるボリュームを制限します。
  • ランタイムプロファイルやリードオンリーのルートファイルシステムなど、他のパラメーターを制限します。
q03.png

本番環境でPSPを使用する際の課題

Pod Security Policyの構成は単調で飽き飽きするプロセスです。 KubernetesクラスターでPSPを有効にすると、構成するPSPのいずれかでデプロイするPodを許可する必要があります。

強力なセキュリティポリシーの実装には時間がかかる場合があります。各アプリケーションのデプロイメントごとにポリシーを生成することは負担です。ポリシーが許容範囲を超えている場合、最小特権アクセスのアプローチを強制していません。ただし、制限が厳しすぎると、ポッドがKubernetesで正常に実行されないため、アプリケーションが破損する可能性があります。

最小限のアクセス要件でPod Security Policyを自動的に生成できると、PSPを簡単にオンボードできます。アプリケーションがまだ動作することを確認せずに本番環境にデプロイすることはできず、手動テストを行うのは退屈で非効率的です。Kubernetesワークロードのランタイム動作に対してPSPを検証できたらどうでしょうか?

Kubernetesネイティブな脅威防止としてPSPを使用する

Pod Security Policiesは、実質的には脅威防止の仕組みです。それらが実施するセキュリティ制約により、攻撃がクラスタ全体に広がるのを防ぎ、一般的なコンテナブレイクアウトアプローチをブロックします。PSPは、AppArmor、SELinux、seccomp、またはLinux機能のようなきめの細かいランタイムセキュリティプロファイルを適用することもできます。これにより、利用可能なルート権限のサブセットをプロセスに提供します。

Pod Security PoliciesはKubernetesプラットフォームの一部であるため、Podの構成を検証し、ランタイム時のアクセス許可を適用する場合、アプリケーションワークロードのパフォーマンスには影響しません。 コンテナインフラストラクチャを改ざんしたり、ホストバイナリとコンテナイメージを変更したりする他のツールは、セキュリティリスクをもたらし、パフォーマンスに影響を及ぼす可能性があります。

Sysdig Secureを使用して本番環境でPod Security Policiesを実装する

Sysdig Secure Kubernetes Policy Advisorは、Pod Security Policiesの作成と検証の両方でユーザーを支援します。

最初のステップは、新しいPSPシミュレーションをセットアップします。さまざまなスコープ(Kubernetes namespaceなど)とさまざまなポリシーで複数のシミュレーションを実行できます。

q04.png

新しいシミュレーションを作成しましょう。Sysdig Secureでは、以前に作成したPod Security Policy定義をアップロードするか、Kubernetes Deployment yaml定義を用いて新しいPSPの構築を支援することができます。

q05.png

Sysdig Secureは、デプロイメント定義のPod仕様の要件を分析し、アプリケーションの最小特権PSPを作成します。これは、特権ポPod、ユーザーがコンテナ、ボリュームなどとして実行できるようにするかどうかを制御します。PSPを微調整し、シミュレーションを実行するnamespaceを定義できます。

q06.png

Kubernetes Policy Advisorを使用すると、セキュリティポリシーの構成にかかる時間が大幅に短縮されました。

次のステップは、ポリシーがアプリケーションを壊さないようにすることです。 Policy Advisorを使用すると、施行前にポリシーを検証できます。これをシミュレーションと呼びます。Sysdig Secureは、デプロイメント定義とランタイムデータを組み合わせて、適用されたPSPがアプリケーションの現在の要件と動作に違反するかどうかを効果的に確認できます。

q07.png

nginxデプロイメントは特権Podであり、ホストネットワークアクセスがあるため、左側のポリシーはアプリケーションを中断します。この動作を許可するためにPSPを拡張するか、ポリシーに適合するようにデプロイメントの特権を減らすかを選択する必要があります。いずれにせよ、アプリケーションデプロイメントにPSPを適用する前に実行させる事によって不都合な挙動を検出できます。

まとめ

Pod Security Policiesは、Kubernetesワークロードのセキュリティを強化する最も興味深い方法の1つです。これらを使用すると、アプリケーションの問題を特定して防止し、最小特権アクセスモデルを確立できます。

PSPの使用は複雑になる可能性があり、検証なしでデプロイすると、アプリケーションが壊れたり、寛容になりすぎたりする可能性があります。Sysdig Kubernetes Policy Advisorは、Pod Security Policiesを自動生成および検証することにより、より迅速かつ効率的にそれらを採用できるようにします。

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top