見出し画像

KubernetesでrunAsUser: 0を使うとどうなる？— root実行のリスクと正しい設定方法

toshi

KubernetesのsecurityContextを設定するとき、runAsUser: 0を指定するとどうなるのか？ なんとなく「root権限で動くのかな？」とは思うけれど、実際の影響やリスクをしっかり理解している人は意外と少ないかもしれません。

「とりあえず動くから root のままでいいや」と設定してしまうと、思わぬセキュリティリスクを招く可能性があります。この記事では、runAsUser: 0の意味やリスク、間違いやすいポイント、そして安全にコンテナを動かすための対策について見ていきましょう！

runAsUser: 0 とは？

KubernetesでrunAsUser: 0を設定すると、そのPod内のコンテナがユーザーID (UID) 0 の権限で実行されることを意味します。

LinuxにおいてUID 0 は特別な意味を持ちます。そう、「rootユーザー」です。つまり、runAsUser: 0を指定したコンテナは、Linuxのスーパーユーザーとして動作することになります。

spec:
  containers:
  - name: my-container
    image: ubuntu:22.04
    securityContext:
      runAsUser: 0  # rootユーザーで実行

この状態だと、コンテナ内のプロセスは制限なしに何でもできる状態になります。これは一見便利ですが、後述するように危険も伴います。

runAsUser: root は書けない！

よくある誤解として、次のように書いてしまうケースがあります。

securityContext:
  runAsUser: root  # ❌ これはエラーになる

実は、この書き方は無効 です。runAsUser に指定できるのは 数値（UID）のみ であり、ユーザー名（rootなど）は使えません。

✅ 正しい書き方

securityContext:
  runAsUser: 0  # rootユーザー（UID 0）として実行

なぜ runAsUser: root は使えないのか？

  • runAsUser は 数値の UID を指定するフィールド。

  • Linuxでは root ユーザーの UID は 0。

  • runAsUser: root は 無効な値 であり、Kubernetes はエラーを出す。

つまり、「root で動かしたいなら runAsUser: 0 を書く」のが正解です。

なぜ root 実行は問題なのか？

「root で動かして何が悪いの？」と思うかもしれませんが、問題はセキュリティリスクにあります。

(1) コンテナが乗っ取られたら…？

もし攻撃者がアプリケーションの脆弱性を突いてコンテナ内に侵入した場合、root権限を持っていると ホストOSや他のコンテナにも影響を及ぼす可能性 があります。

たとえば、root 権限があると /etc/shadow（パスワード情報が格納されているファイル）を読めたり、apt install で好きなパッケージをインストールしたりすることが可能です。さらに、悪意のあるプロセスを仕込んでホストOSまで乗っ取る…という事態もあり得ます。

(2) 特権コンテナと組み合わせると最悪

Kubernetesでは、privileged: true を設定すると、コンテナはホストのカーネルに直接アクセスできます。もしrunAsUser: 0とprivileged: trueがセットで設定されていたら… もはや「ホストOSにフルアクセスOK！」と言っているようなものです。

(3) Kubernetesの制約を回避される可能性

Kubernetesのセキュリティ機能 (PodSecurityStandards など) では、多くの場面で root 実行を制限する仕組みがあります。しかし、runAsUser: 0を設定すると、そのルールをかいくぐることも可能になります。

安全な設定方法

では、どうすれば安全にコンテナを実行できるのでしょうか？

(1) 非 root ユーザーを使う

Kubernetesでは、コンテナを**一般ユーザー（非 root ユーザー）**として実行することができます。例えば、UID 1000 の一般ユーザーで動作させる場合は次のように設定します。

spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu:22.04
    command: ["sleep", "4800"]
    securityContext:
      runAsUser: 1000  # UID 1000 の一般ユーザーで実行

こうすることで、万が一コンテナが乗っ取られても、攻撃者がroot権限を持つことはありません。

(2) PodSecurityStandards を活用する

KubernetesのPodSecurityStandards (PSS) を利用すれば、Podのセキュリティレベルを統一できます。特にrestrictedプロファイルを適用すると、デフォルトで root 実行が禁止されます。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  runAsUser:
    rule: MustRunAsNonRoot  # root 実行禁止

PSSを適用することで、誤って root 実行のコンテナを作成してしまうリスクを減らせます。

まとめ

  • runAsUser: 0 を設定すると、コンテナが root ユーザーとして動作する

  • runAsUser: root はエラーになる → runAsUser: 0 を使う

  • root 実行はセキュリティリスクが高く、ホストOSへの影響も及ぼす可能性がある

  • 非 root ユーザー (runAsUser: 1000 など) での実行が推奨される

  • PodSecurityStandards や PodSecurityPolicy を活用して root 実行を制限する

「とりあえず root で動かす」は一見楽ですが、後々のセキュリティリスクを考えると、最初から非 root ユーザーで運用するのがベスト です。もし root 実行がどうしても必要な場合は、その範囲を最小限に抑える工夫をしましょう！ 🚀

いいなと思ったら応援しよう！