🤔 allowPrivilegeEscalation: false – 設定するだけで本当に安全なのか？ (privileged: trueとの完全比較)

10月 23, 2026

—

こんにちは！Kubernetesのセキュリティ設定を扱う際、securityContextフィールドでallowPrivilegeEscalationとprivilegedという似た名前の2つのオプションに遭遇することがあります。どちらも権限に関連しているように見えるため、混同しやすいですよね。

「両方ともfalseにしておけば一番安全なのでは？」と考えるかもしれませんが、これら2つの正確な役割を理解することで、より洗練された安全なセキュリティポリシーを確立できます。🔒

今日は、allowPrivilegeEscalation: falseが具体的にどのような役割を果たすのか、そして最も強力なオプションであるprivileged: trueとは何が違うのか、徹底的に掘り下げてみましょう！

1. allowPrivilegeEscalation: false – 内部権限昇格ブロッカー 🛡️

このオプションの核心は、コンテナ内部で実行されたプロセスが、親プロセスよりも多くの権限を獲得するのを防ぐことです。

少し難しいですか？例え話で説明しましょう。

平社員（子プロセス）が会社に入社（コンテナ実行）しました。しかし、この平社員が会社内部の秘密通路（setuidバイナリ）を利用して、突然社長（root）権限を得ようと試みます。allowPrivilegeEscalation: falseは、まさにこの秘密通路を利用した「内部昇進」を根本的に阻止するセキュリティ要員のようなものです。

どのように機能しますか？

この設定は、Linuxカーネルのno_new_privsフラグを制御します。allowPrivilegeEscalation: falseに設定すると、当該コンテナで実行されるすべてのプロセスにno_new_privsフラグが有効になります。このフラグがオンになると、execve()システムコールを介して他のプログラムを実行しても、UIDやGIDを変更すること（例：setuid、setgidビットが設定されたファイルの実行）が禁止されます。

簡単な例：コンテナがappuser（UID 1000）として実行中だと仮定しましょう。

allowPrivilegeEscalation: true (デフォルト): コンテナ内部にsudoやpasswdのようにsetuidが設定されたファイルがある場合、appuserはこのファイルを実行してコンテナ内部のroot（UID 0）権限を獲得できます。
allowPrivilegeEscalation: false: appuserが同じファイルを実行しても、カーネルが権限変更を阻止します。結果としてプロセスはrootになれず、権限昇格の試みは失敗します。

つまり、このオプションはコンテナが開始された権限のままでのみ動作するように強制する役割を果たします。

2. privileged: true – ホスト権限マスターキー 🔑

privileged: trueはallowPrivilegeEscalationとは次元の異なる話です。このオプションは、コンテナとホスト（Node）間のすべてのセキュリティ境界を破壊します。

先ほどの例え話をもう一度使いましょう。privileged: trueは、平社員に会社建物全体のマスターキーを渡してしまうようなものです。会社内部のどんな部屋でも開けることができ、サーバールーム、社長室など、あらゆる場所にアクセスできるようになります。

何が起こりますか？

privileged: trueに設定されたコンテナは、次のような強力な権限を持ちます。

ホストのすべてのデバイス(/dev)にアクセスできます。
Seccomp、AppArmorなど、コンテナを隔離するすべてのLinuxセキュリティプロファイルが無効化されます。
ホストカーネルのすべてのcapabilitiesを獲得します。

事実上、コンテナではなく、ホストで直接実行されるプロセスとほぼ同じ権限を持つことになります。したがって、このオプションはCNIプラグインやストレージドライバのように、ホストレベルの制御が必須なシステムデーモン以外では絶対に使うべきではありません。 😨

3. 核心比較：では、両者の違いは？

それでは、2つのオプションの違いを表で明確に整理してみましょう。


区分	allowPrivilegeEscalation: false	privileged: true
観点	コンテナ内部 (プロセスが親よりも強くなるのを防止)	コンテナ vs ホスト (コンテナがホストの権限を持つことを許可)
動作方式	Linuxカーネルのno_new_privsフラグ制御	コンテナ隔離メカニズム全面無効化
比喩	🕵️‍♂️ 内部昇進（権限昇格）を阻止するセキュリティ要員	🗝️ 建物全体を開けるマスターキー
主な使用用途	すべての一般的なアプリケーションPodの基本セキュリティ強化	⚙️ CNI、ストレージドライバなどシステムPod

—

2つのオプションの関係とベストプラクティス

privileged: trueコンテナは、自動的にallowPrivilegeEscalationがtrueであるかのように動作します。すでにホストのすべての権限を持つマスターキーがあるのに、コンテナ内部で権限を昇格させることは意味がないからです。
したがって、Kubernetesはprivileged: trueとallowPrivilegeEscalation: falseを同時に設定することを許可しません。

⭐ ベストプラクティス：

ほとんどの一般的なアプリケーションコンテナでは、セキュリティを最大限に強化するために、privileged: falseとallowPrivilegeEscalation: falseを両方とも明示的に設定するのが最適です。

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: my-app
    image: my-image
    securityContext:
      privileged: false
      allowPrivilegeEscalation: false # これがベストプラクティスです！

これで、2つのオプションの違いが明確に理解できましたか？allowPrivilegeEscalation: falseはコンテナの内部セキュリティを強化する重要な設定であり、privileged: trueはコンテナの境界を破壊する強力だが危険なオプションであることをぜひ覚えておいてください！