Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年2月26日にMatt Brownが投稿したブログ(https://www.sysdig.com/blog/leveling-up-kubernetes-posture-from-baselines-to-risk-aware-admission)を元に日本語に翻訳・再構成した内容となっております。
多くの組織において、Kubernetesのポスチャー管理は、強く方針を打ち出したセキュリティモデルから始まるのではなく、一般的なガードレールの小規模なセットから始まる傾向があります。
一部のチームは、クラスターのアクセス制御を信頼し、開発者が「正しいことをする」ことを期待して、デフォルトのKubernetesの動作に全面的に依存しています。ほかのチームは、Pod Security Standards（PSS）をベースラインとして採用し、Kubernetesネイティブのガードレールを使用して、最も明らかに安全でないワークロードをブロックしています。
これらのアプローチが一般的であるのは、次の理由によります。
- Kubernetesエコシステムに組み込まれている
- プラットフォームチームが比較的容易に採用できる
- 複数のクラスターにわたって適用する際の摩擦が低い
実際には、これは最初のポスチャーとしてはかなりうまく機能します。明らかな構成ミスは阻止され、期待値が設定され、チームは運用上の大きなオーバーヘッドを招くことなく前に進めることができます。
Kubernetes のベースラインが不十分になり始めるところ
最新のKubernetes環境は、これらのベースラインコントロールが元々設計された環境とは大きく異なります。クラスターはもはやステートレスなアプリケーションワークロードを実行しているだけではありません。これらには日常的に次のものが含まれます。
- 特権を持つインフラストラクチャコンポーネント
- セキュリティ要件が不透明、または十分に文書化されていないサードパーティ製ソフトウェア
- クラウドAPI、アイデンティティシステム、機密データと直接やり取りするワークロード
Pod Security Standards は意図的に粗い粒度で設計されています。これらは「これは一般的に安全か？」という問いに答えるには有効ですが、ここで安全かどうか、このワークロードにとって安全かどうか、あるいはそもそもそれを許可することでどのようなリスクを受け入れているのかといった、より文脈に即した問いに答えるようには設計されていません。
その結果、よくある運用上のトレードオフが生じます。チームは、広範に適用を緩和してリスクを受け入れるか、あるいは厳格なベースラインを適用して実際のワークロードが破綻するにつれて増え続ける例外のリストを徐々に蓄積するかのいずれかになります。やがて、それらの例外が常態化し、本来のセキュリティシグナルはその価値を失います。
ポスチャーが（まだ）進化していない理由
Kubernetesに組み込まれたPod Security Admission（PSA）を通じて適用されるPod Security Standardsは、多くのチームがアドミッションコントロールを導入する際のデフォルトの方法となっています。PSAは予測可能で、よく理解されており、意図的にその適用範囲が限定されています。
課題は、チームがPSSやPSAで表現することを想定された範囲の境界に達したときに現れます。環境が成熟するにつれて、ポスチャに関する判断はより文脈依存となり、トレードオフの管理はより困難になります。
- 表現力の限界:
PSAはPodを広範なセキュリティレベルに照らして評価しますが、ワークロードのアイデンティティ、所有者、環境、または意図について考慮することはできません。 - 適用範囲の大まかさ:
意思決定は通常、ネームスペースレベルで行われるため、より広範に門戸を開くことなく、範囲が限定され十分に理解されたケースにおいてリスクのある機能を許可することが困難になります。 - 例外圧力:
実際のワークロードが増えていくにつれて、チームは適用を緩和するか、あるいは実質的に有効なコントロールを回避するネームスペースを切り出すかのいずれかを強いられます。
一部のチームは、表現力を取り戻すために、より柔軟なアドミッションフレームワークを検討します。OPA GatekeeperやKyvernoのようなオープンソースツールは強力な構成要素を提供しますが、同時に、ポリシーの設計、テスト、チューニング、および継続的な保守に多大な労力を必要とします。多くの組織にとって、その追加の複雑さは明確な次の一歩というよりも障壁となります。
その結果、自然な停滞が生じます。PSAは安全で組み込みのベースラインとして残り、それを超える取り組みは、大規模に運用するにはコストが高くリスクがあると感じられるようになります。
ポスチャーを意思決定のポイントとして再定義する
これまでのところ、Kubernetesのポスチャーは主に静的なチェックリストとして扱われてきました。すなわち、ベースラインを適用し、それを一貫して強制し、例外が発生した場合に対処するというアプローチです。この方法は、ワークロードが均一で、リスクを一般化しやすい場合には有効です。
しかし実際には、ポスチャーは静的なものではありません。それは、ワークロードが作成または更新されるたびに、Kubernetesがすでに行っている意思決定なのです。
Kubernetesでは、その意思決定はアドミッション時に行われます。Podが実行される前に、APIサーバーはそれを許可するか、拒否するか、あるいは可視性を確保したうえで許可するかを評価します。Pod Security Admissionは、広範なセキュリティレベルを用いてこの意思決定を適用し、必要最低限の基準を確立します。しかし、それが行わないのは、文脈に基づいた判断です。
リスク認識型のポスチャモデルは、この同じ意思決定ポイントを基盤としながら、ワークロードの実行を許可する前に考慮される要素を拡張します。普遍的な基準を満たしているかどうかだけを問うのではなく、チームは実際の環境におけるワークロードのリスクを評価することができます。
アドミッション時には、たとえば次のような問いが含まれる場合があります。
- このワークロードはどこで実行され、何にアクセスできますか?
- どのようなアイデンティティとして運営されているのか、そしてそのアイデンティティはどの程度広く信頼されているのか？
- どのような権限またはホストアクセスが必要ですか?
- どのイメージがデプロイされていますか。また、リスクが高いことがわかっていますか?
- 侵害された場合、このワークロードは現実的にどのような影響を与える可能性がありますか？
ポスチャーがチェックリストではなく決定事項として扱われるようになれば、リスクの高い設定があらゆる場所で単に「許可」または「阻止」されることはもうありません。それらは文脈の中で評価され、強制は偶発的なものではなく意図的なものになります。
この転換はPod Security Standardsを置き換えるものではなく、それを基盤として発展させるものです。PSSは最低限の基準を確立します。その上にリスク認識型のアドミッションが文脈を適用することで、正当なユースケースを損なうことなく、ワークロードがランタイムに到達する前に安全でない状態を防ぐことが可能になります。
実際の PSA: Amazon EKS の具体的な例
理論上、Pod Security Admissionの使用は単純です。Pod Security Standardを選択し、それをネームスペースに適用すれば、Kubernetesはそのベースラインを満たさないものをすべてブロックします。インストールするものはなく、運用するポリシーエンジンもありません。これは文字どおりAmazon EKSに組み込まれています。
実際には、その体験は効果的である一方で、硬直的でもあります。
実際のPSAはどのようなものか
restricted 標準を強制するために、ネームスペースを作成し、それにラベルを付与します。
コマンド:
kubectl create namespace demo-app
kubectl label namespace demo-app \
pod-security.kubernetes.io/enforce=restrictedこの時点から、そのネームスペースにアドミットされるすべてのPodは、同じプロファイルに対して評価されます。
特権アクセスを要求するデプロイメントを作成します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-test
labels:
app.kubernetes.io/name: nginx-test
app.kubernetes.io/component: demo
spec:
replicas: 1
selector:
matchLabels:
app: nginx-test
template:
metadata:
labels:
app: nginx-test
spec:
containers:
- name: nginx
image: nginx
securityContext:
privileged: trueマニフェストを適用すると、Podは直ちに拒否されます。エラーは、そのワークロードがrestricted Pod Security Standardに違反していることを示しており、デプロイメントはそこで停止します。
kubectl apply -f nginx.yaml -n demo-app
Warning: would violate PodSecurity "restricted:latest": privileged (container "nginx" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")これはPSAが設計どおりに機能している状態です。
欠けているのは文脈です。そのワークロードがなぜ存在するのか、誰が所有しているのか、あるいは要求されている特権がこの環境で想定されるものなのか、といった理解がありません。判断は二値的で、そのネームスペース全体に対して適用されます。
そのワークロードが正当な理由でより高い権限を必要とする場合、選択肢は、そのネームスペース内のすべてに対する強制を緩めるか、ワークロードを別の場所へ移すかのどちらかしかありません。時間が経つにつれて、例外が積み重なることでポスチャは逸脱していきます。それは注意不足からではなく、表現力の不足によるものです。
なぜこれが重要なのか
Pod Security Admissionは、Kubernetesネイティブの強固な最低基準を確立します。ワークロードが実行される前に、安全でないデフォルトを確実にブロックします。しかし、それが行わないのはリスクについて判断することです。「デフォルトでは安全でない」状態と「リスクはあるが意図的である」状態を区別するには、PSAが評価するよう設計されていない文脈が必要です。
そのギャップこそが、チームがよりリスク認識型のアドミッション判断を求め始める地点となります。
ベースラインを超えて：Sysdigによる文脈の追加
Pod Security Admissionは明確な失敗をもたらしました。設計どおり、restrictedネームスペース内の特権コンテナをブロックしました。
これがベースラインです。では、同じデプロイメントをもう一度実行してみましょう。
ネームスペースを超えた微妙な違い
PSAは意図的に厳格です。ネームスペースの境界で、Podをセキュリティレベルに照らして評価します。これはベースラインを確立するには優れていますが、その一方で、判断は画一的になります。
- restrictedでは失敗します
- ネームスペースを緩めれば通過します
- そして、そのネームスペース内のすべてのワークロードが同じ扱いを受けます
Sysdigのアドミッションコントロールは、同じ「アドミッション時の意思決定ポイント」を維持しつつ、ポスチャーの適用方法により高い精度をもたらします。
privileged: true を文脈なしで評価するのではなく、Sysdigはチームがすでに持っている情報を用いてポスチャの判断範囲を限定できます。たとえば、次のようなものが含まれます。
- 標準的なKubernetesのアプリケーションラベル（app、component、instance）
- 「これはそのチャート由来である」と識別するためのHelmのオリジン
これは、「ネームスペース ＝ ポリシー」という制約に縛られなくなることを意味します。
ラベルやHelmメタデータなどのワークロード属性に基づいてポスチャの期待値を限定できるため、ネームスペースレベルの境界のみに依存することなく、クラスターやネームスペース全体にわたって、よりきめ細かな強制が可能になります。
二値的な強制からプロファイル主導のポスチャーへ
ポスチャーがネームスペースの境界に厳密に結び付けられなくなると、より興味深いことが可能になります。
もはや、どこにでも単一のセキュリティレベルを適用することに限定されません。代わりに、異なるワークロードのグループに対して異なるコントロールセットを適用できます。
PSAでは、強制は実質的に二値的です。
- ネームスペースがrestrictedを強制するか、しないかです。
- Podがそのレベルに違反するか、通過するかです。
Sysdigでは、ポスチャーを複数の標準やコントロールセットに照らして評価し、ワークロードのアイデンティティに基づいて選択的に適用することができます。
つまり、次のようなさまざまなリソースグループを、まったく異なる期待値に対して評価できるということです。
- プラットフォームのワークロードは、CISベンチマークに準拠したコントロールに照らして評価できます。
- アプリケーションのワークロードは、OWASPに準拠したコントロールに照らして評価できます。
- 機密性の高いワークロードには、追加のカスタム組織チェックを含めることができます。
これにより、ポスチャーはもはや単なるPSSではなくなります。より柔軟になります。より現実的になります。なぜなら、実際のクラスターは一様ではないからです。
PSAでは表現できない微妙な違い：2つの特権ワークロード
どちらも特権アクセスを要求する2つのPodを想像してください。
- 既知のインフラストラクチャーデーモンセット、プラットフォームエンジニアリングが保守し、承認されたHelm チャートで導入
- ランダムなアプリケーションワークロード、見慣れないイメージからデプロイされ、明らかに赤信号が出ています
PSAは両方について同じことを見ています。
privileged: true
Sysdigはそのシグナルから開始することもできますが、ワークロードを区別できるため、たとえば次のような情報を通じて、異なる判断に到達することができます。
- ラベルや所有者メタデータ（プラットフォームかアプリケーションか）
- Helmチャートのアイデンティティ（既知のリリース／チャートか不明なものか）
それらは異なるリスクプロファイルです。
一方は、理解され意図されたものであるため、厳格なガードレールのもとで許可されるかもしれません。もう一方は拒否されます。
これが進化です。ポスチャーは静的なチェックリストであることをやめ、意図を表現するためだけにネームスペース全体の設計をやり直すことなく、情報に基づいた的確な判断へと変わります。
シグナルを失うことのない、きめ細かな例外対応
ベースラインのみの強制における運用上の課題の一つは、例外の拡大です。正当なワークロードがポリシーに違反した場合、チームはネームスペースレベルで強制を緩和したり、意図せず全体のポスチャ強度を低下させる広範な例外を設けたりすることがよくあります。
より精緻なアドミッションモデルでは、例外を限定的に適用することが可能になります。ネームスペース全体の強制を無効化する代わりに、チームははるかにきめ細かなレベルで例外を定義できます。それは、単一のワークロードに対する単一のコントロール検出にまで限定することも可能です。
これにより、例外が明示的で、文書化され、適用範囲が限定されたものになります。目的は例外を排除することではなく、例外が恒久的なポリシーのギャップになることを防ぐことです。きめ細かさはシグナルを維持します。これにより、運用上の現実を認識しつつ、強固なポスチャコントロールを維持することが可能になります。
脆弱性を認識したアドミッション
ここで、アドミッションコントロールはよりリスクに基づいたものになります。
Pod Security Admissionは、コンテナイメージの脆弱性ポスチャーを評価しません。次のような点について可視性を持っていません。
- イメージに重大なCVEが含まれているかどうか
- それらのCVEが悪用可能かどうか
- 修正が利用可能かどうか
Sysdigのアドミッションコントロールは、脆弱性の検出結果をアドミッションの判断に直接組み込むことができます。
たとえば、次のようなポリシーを定義できます。
- 修正が利用可能な重大な脆弱性を含むイメージをブロックする
- 特定のCVEを含むイメージをブロックする
- 特定のパッケージを含まないイメージのみを許可する
- 本番ネームスペースではHigh以上の脆弱性がゼロであることを要求する
同じnginxの例を改めて見てみると、そのワークロードは単に特権であるという理由だけでなく、次のような理由によって拒否される可能性があります。
- そのイメージに複数の重大な脆弱性が含まれている
- 修正が30日以上前から利用可能である
- 既知のエクスプロイトが存在する
- そのワークロードが本番ネームスペースにデプロイされている
kubectl apply -f nginx.yaml -n demo-app
Error from server: error when creating "nginx.yaml": admission webhook "vac.secure.sysdig.com" denied the request:
[VM Engine] Failed checks for container nginx. Failing policies: [AC Policy]
Violations:
x Severity greater than or equal criticalそれは構成のみに基づく判断ではありません。リスクに基づいたポスチャーの判断です。
ランタイムの現実
アドミッションコントロールは、特定の時点で判断を行います。ワークロードが起動する前に、構成、イメージのリスク、デプロイメントの文脈を評価します。しかし、評価できないのは振る舞いです。
ワークロードは、すべてのポスチャーコントロールを満たしていても、デプロイ後に悪用される可能性があります。適切に構成され、厳しく制限されたアプリケーションであっても、ソフトウェアの欠陥、依存サービスの設定ミス、あるいはランタイムでのみ表面化するロジックエラーを含んでいる可能性があります。
多くの環境では、特定のワークロードに意図的に高い特権が付与されています。その昇格は運用上の理由から必要である場合がありますが、ワークロードが侵害された場合の潜在的な影響も増大させます。
厳しく制限されている場合でも、意図的に特権が付与されている場合でも、侵害されたワークロードは、その認証情報を悪用し、環境内を横断的に移動し、ファイルシステムを変更し、予期しないプロセスを実行する可能性があります。これらの行為はKubernetesの仕様には可視化されておらず、アドミッション時に完全に判断することはできません。
ポスチャーコントロールは、ワークロードが実行を開始する前に既知の安全でない状態を防ぎます。ランタイムセキュリティは、その判断が行われた後に何が起こるかに対処します。
アドミッションは「このワークロードの起動を許可すべきか？」という問いに答えます。
ランタイムは「いま実行されているが、期待どおりに振る舞っているか？」という問いに答えます。
現代のKubernetes環境では、両方のコントロールが必要です。構成のコンプライアンスはリスクを低減しますが、振る舞いの安全性を保証するものではありません。
まとめ
Kubernetesのポスチャーは、多くの場合、実践的なガードレールから始まります。Pod Security Standardsは、明らかな設定ミスをブロックし、全体のセキュリティ水準を引き上げる、強力で組み込みのベースラインを確立します。
しかし、環境が成熟するにつれて、ネームスペース全体に一律で適用される単一の強制レベルは制約となります。ワークロードは、信頼度、公開範囲、運用上の要件において異なります。効果的なポスチャには、その現実を反映した判断が求められます。
アドミッションを静的なチェックリストではなく意思決定のポイントとして捉えることで、チームは二値的な強制を超えることができます。ポスチャーは、ワークロードのアイデンティティ、ベンチマーク標準、脆弱性リスクに整合させることが可能です。それは一律ではなく、意図的に適用されます。
アドミッションはワークロードの開始前にリスクを低減しますが、その後に発生するすべての事象を考慮することはできません。そのため、ランタイムの可視性と強制は依然として不可欠です。Kubernetesのセキュリティは単一のコントロールではなく、デプロイから実行に至るまでの一連の情報に基づいた意思決定なのです。