rootユーザーで実行されるコンテナ

rootで実行することが危険な理由

多くのコンテナイメージはデフォルトでroot（UID 0）として実行されます。コンテナの分離はある程度の保護を提供しますが、コンテナエスケープの脆弱性とrootアクセスの組み合わせにより、攻撃者がホストノードのrootを取得する可能性があります。

セキュリティコンテキストなしの例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-user-app
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: app
          image: python:3.12
          command: ["python", "-m", "http.server", "8080"]
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi

バリデーターが検出する問題

• 警告: PodレベルでsecurityContext.runAsNonRootが設定されていません

非root実行の強制

PodレベルでrunAsNonRoot: trueを設定して、コンテナがrootとして実行されるのを防ぎます：

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000

rootが必要なイメージの修正

1. Dockerfileに非rootのUSERディレクティブを使用してイメージを再ビルド
2. rootアクセス付きのinitコンテナでファイルパーミッションを設定し、メインコンテナを非rootで実行
3. ボリュームのファイル所有権管理に**fsGroupを使用**

Pod Security Standards

Kubernetes Pod Security Standardsは3つのレベルを定義しています：

• Privileged: 無制限（非推奨）
• Baseline: 既知の権限昇格を防止
• Restricted: 厳しく制限、非root強制、capabilities削除

Restrictedプロファイルを使用すると、アドミッション制御により自動的にrunAsNonRoot: trueが強制されます。