seccompとSELinuxでノード堅牢化【CKS第6回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第6回です。第5回までは、リクエストが API Server に届いてから何が起きるかを扱ってきました。本回はそこから一段下へ降り、コンテナがカーネルに対して何を要求できるかを絞ります。

本回の主題は 1 文で書けます。ホストが Enforcing でも、コンテナが SELinux で拘束されているとは限りません。その差を実機で確認し、埋めます。

扱うのは カーネル層（LSM / syscall / capabilities）に限定します。ノード OS そのものの攻撃面削減——稼働サービスの棚卸し、sudo と SSH の権限設計、firewalld によるノード外通信の制限——は第7回の担当です。同じ D3 ドメインを 2 回に分け、本回が「カーネルが何を止めるか」、次回が「そもそも何を動かさないか」を受け持ちます。

第6回のスコープ・今ここマップ#

本回から CKS ドメイン D3: System Hardening（配点 10%） に入ります。D3 は 4 つのコンピテンシーからなり、そのうち本回が担当するのは 1 つだけです。

公式文言に SELinux の名前はありません。ただし such as が示すとおり AppArmor と seccomp は「カーネル堅牢化ツール」の例示です。SELinux は同じ強制アクセス制御（MAC）の別実装であり、本書ラボ（AlmaLinux）ではこちらが実機の主役になります。試験環境（Ubuntu）では AppArmor が動きます。この差の扱い方は、本節の後半で 3 段構えとして整理します。

第3巻 19 回のうち、現在位置は次のとおりです。

第1部 第3巻オリエンテーション
    第1回: 第3巻スコープ + CKA 境界 + 4C/脅威モデル + Kubestronaut

第2部 クラスタ堅牢化（D1/D2）
    第2回: kube-bench + CIS ベンチマーク修復 + バイナリ検証（D1）
    第3回: NetworkPolicy 完全設計 + ノードメタデータ保護 + TLS Ingress（D1）
    第4回: RBAC 監査 + ServiceAccount トークン管理（D2）
    第5回: API Server 堅牢化 + kubeadm アップグレード（D2）

第3部 OS / ノード堅牢化（D3）
  ★ 第6回: カーネル層の強制アクセス制御（SELinux/seccomp/capabilities/AppArmor）（D3）  ← 今ここ
    第7回: ホスト OS の攻撃面最小化と権限管理（D3）

本回の起点#

起点は第5回の完了状態です。第2巻から引き継いだ 9 VM 構成（Control Plane Node 3 台 + Workload Node 2 台 + 作業端末・レジストリ・LB・プロキシ）が稼働している前提で進めます。

本回で初めて出てくる 2 つの用語#

第3巻の第1回から第5回までで 1 度も使っていない語が 2 つあります。以降の説明の前提になるので、先に定義します。

もう 1 つ、shim という語が やってみよう① のステップ3 で出てきます。そちらは実物を見ながら定義したほうが分かりやすいので、その場で説明します。

AppArmor をどう扱うか——本書の 3 段構え#

本回のタイトルには AppArmor が入っていますが、AlmaLinux ラボでは AppArmor のプロファイルを適用できません。カーネルの LSM が SELinux だけだからです。AppArmor はカーネル機能であり、コンテナはホストのカーネルを共有します。したがって Docker を挟んでも kind を挟んでも、ホストカーネルに AppArmor が無い以上は動きません。試験環境（Ubuntu）では動きます。

この差を曖昧にしないために、本書は次の 3 段構えを取ります。

演習の進め方#

この回のゴール#

本回を終えると、次のことができるようになります。到達できたかは記事末の「やってみよう」と「理解度チェック」で確認します。

• seccomp（RuntimeDefault / Localhost）で syscall を絞り、/proc/1/status の Seccomp で効果を確認できる
• enable_selinux の有無でコンテナが container_t か spc_t かが変わることを実機で確認し、拘束を有効化できる
• 意図的に拒否を起こし、AVC の scontext / tcontext / tclass を読んで正しい対処を選べる（dontaudit により AVC に出ない拒否があることも知っている）
• Kubernetes のボリュームのラベル付けは kubelet の自動リラベルで行われ、hostPath は対象外であることを説明できる
• AppArmor の新旧記法と、非対応ノードで Pod がどう失敗するかを説明できる
• Control Plane に同じ設定を入れると何が壊れるかを理由とともに説明できる

なぜ D3 を D4 より前に置くのか（部品 → 束）#

CKS のドメイン順で言えば D4（Minimize Microservice Vulnerabilities）は D3 の次です。本書もその順に並べていますが、それは単に番号順だからではありません。本回で扱うものが「部品」で、第8回で扱う Pod Security Standards が「束」だからです。

4C モデル（Cloud → Cluster → Container → Code）で言えば、本回は Container と Node の境界にある OS 層を固めます。そして第8回の PSS Restricted は、seccompProfile: RuntimeDefault / capabilities.drop: [ALL] / runAsNonRoot: true / allowPrivilegeEscalation: false といった個々の設定を要件として束ねたものです。

部品を先に理解しておくと、第8回で「Restricted がなぜその組み合わせを要求するのか」を暗記ではなく理由で説明できます。逆に束から入ると、PSS の要件表を丸暗記することになります。CKS が問うのはそこではありません。

上流がすでに入れている設定を見る#

「部品が実務で使われている」ことは、自分のクラスタで確かめられます。kubeadm v1.36 が生成する Control Plane の static Pod には、すでに securityContext.seccompProfile が入っています。

実行コマンド（k8s-cp-01 上・developer）：

$ sudo grep -A2 "securityContext" /etc/kubernetes/manifests/etcd.yaml

実行結果：

  securityContext:
    seccompProfile:
      type: RuntimeDefault

同じものが kube-apiserver.yaml にも入っています。上流のインストーラが既定で入れている＝ CKS が求める最低ラインだと考えてください。自分たちのワークロードにこれが入っていないなら、それは Control Plane より緩い状態にあるということです。

本回の やってみよう③ で、fanclub-backend に同じ RuntimeDefault を入れます。上流に追いつく作業だと考えると位置づけが分かりやすくなります。

seccomp（syscall フィルタ）#

seccomp（secure computing mode）は、プロセスが発行できる syscall（システムコール）を制限するカーネル機能です。コンテナが「そもそもカーネルに何を頼めるか」を減らします。Kubernetes では securityContext.seccompProfile で指定します。

最小の書き方は次の 3 行です。

securityContext:
  seccompProfile:
    type: RuntimeDefault

注意したいのは、Kubernetes の既定が Unconfined である点です。何も書かなければ syscall フィルタは掛かりません。Docker で docker run したときの既定とは違います。

効いていることをどう確認するか#

マニフェストに書いたかどうかではなく、プロセスに実際に掛かっているかを見ます。Linux は seccomp の状態を /proc/<pid>/status に出しているので、コンテナの PID 1 を読みます。

確認用の Pod を 1 つ用意します。seccomp-test.yaml（k8s-ops 上で作成）：

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-test
spec:
  nodeName: k8s-wl-02
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]

実行コマンド（k8s-ops 上・developer）：

$ kubectl apply -f seccomp-test.yaml
$ kubectl exec seccomp-test -- grep -E "Seccomp|NoNewPrivs" /proc/1/status

実行結果（seccompProfile: RuntimeDefault を付けた検証 Pod）：

NoNewPrivs:	0
Seccomp:	2
Seccomp_filters:	1

Seccomp: 2 が filter mode（SECCOMP_MODE_FILTER）です。値の意味は次のとおりです。

本書ラボの fanclub-backend は現状 Seccomp: 0 です。やってみよう③ でここを 2 にします。

確認が済んだら消しておきます。

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod seccomp-test

privileged との関係#

privileged: true のコンテナでは seccomp が無視されます。 プロファイルを書いても掛かりません。特権コンテナは「カーネルへの要求を制限しない」ことを目的にした設定なので、syscall フィルタと同居しないという理解でよいです。

したがって seccomp は特権を落とすこととセットで設計します。「seccomp を入れたから安全」ではなく、「特権を落としたうえで seccomp を入れたから安全」です。この関係は 後述の やってみよう① でも calico-node の実例として出てきます。privileged なコンテナは SELinux でも同じく拘束されません。

Localhost プロファイルの記法#

ランタイム既定では足りず、自分で syscall を選びたい場合は Localhost を使います。プロファイルの JSON を各ノードの /var/lib/kubelet/seccomp/profiles/<name>.json に置き、次のように参照します。

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/deny-chmod.json

localhostProfile は /var/lib/kubelet/seccomp/ からの相対パスです。先頭に / は付けません。ここは試験でも間違えやすい箇所です。実演は やってみよう④ で行います。

プロファイルが無いときの失敗の形#

指定したプロファイルがそのノードに無いと、Pod は起動しません。どういうステータスで止まるかを先に知っておくと、切り分けが速くなります。

NAME                   READY   STATUS                 RESTARTS   AGE
seccomp-missing-test   0/1     CreateContainerError   0          25s

イベントには理由がそのまま出ます。

  Warning  Failed  kubelet  Error: failed to create containerd container:
  cannot load seccomp profile "/var/lib/kubelet/seccomp/profiles/nonexistent.json":
  open /var/lib/kubelet/seccomp/profiles/nonexistent.json: no such file or directory

kubectl get pod の STATUS 列に出るのは Pending でも ImagePullBackOff でもなく CreateContainerError です。コンテナが 1 つも起動していないので status.phase 自体は Pending のまま、という組み合わせになります。試験で「Pod が起動しない」原因を切り分けるとき、このステータス名から seccomp を疑えるようにしておいてください。実物は やってみよう④ のステップ3 で出します。

ノード側で底上げする選択肢#

Pod ごとに seccompProfile を書いて回るのは漏れます。kubelet の KubeletConfiguration に seccompDefault: true を設定すると、seccompProfile を書いていない Pod のクラスタ既定を RuntimeDefault にできます。1 Pod ずつ書く運用より確実です。

ただし、既存ワークロードが必要としている syscall が既定プロファイルで塞がれていると壊れます。段階導入（一部ノードから、あるいは Unconfined を明示した例外を用意しながら）が要ります。本書ラボでは有効化しません。 設定項目は kubernetes.io/docs に載っているので試験中も参照できます。

なお第5回で確認したとおり、kubeadm クラスタで kubelet 設定の正本は kubelet-config ConfigMap です。/var/lib/kubelet/config.yaml だけを直しても kubeadm upgrade node で消えます。seccompDefault を本番で入れるなら ConfigMap 側から入れてください。

Linux capabilities（drop ALL + 最小 add）#

root 権限は 1 枚岩ではなく、capabilities という単位に細分化されています。「ネットワーク設定を変えられる」「他ユーザーのプロセスに signal を送れる」「1024 番未満のポートに bind できる」といった能力が個別のフラグになっています。

CKS の定石はすべて drop してから必要なものだけ add することです。

securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE

NET_BIND_SERVICE が要るのは 1024 番未満の特権ポートに bind するときです。fanclub-backend は 8080 番で待ち受けるので不要で、drop: [ALL] だけで動きます。「とりあえず NET_BIND_SERVICE を足す」のは、要件を確認していないだけの add です。

現状を確認する#

実行コマンド（k8s-ops 上・developer）：

$ kubectl get deploy fanclub-backend -n fanclub -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{" => "}{.securityContext}{"\n"}{end}'

実行結果：

backend => {"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"readOnlyRootFilesystem":true,"runAsNonRoot":true,"runAsUser":10001}

第1巻第15回で入れた 5 項目がそのまま残っています。seccompProfile が無いことも、この 1 行から読めます。

init コンテナとサイドカーを含めて見るなら、次のように 3 つのリストを並べて出します。

実行コマンド（k8s-ops 上・developer）：

$ kubectl get deploy fanclub-backend -n fanclub -o jsonpath='{range .spec.template.spec.initContainers[*]}{.name}{" => "}{.securityContext}{"\n"}{end}'

実行結果（securityContext が無いので名前の後ろが空になります）：

wait-for-db =>
log-shipper => 

log-shipper が initContainers 側に出てくるのは、これが restartPolicy: Always を持つネイティブサイドカーだからです。Kubernetes のネイティブサイドカーは initContainers に書きつつ、Pod の生存中ずっと動き続けます。Pod が 2/2 に見えるのはこのサイドカーの分です。

SELinux の基礎（ラベルの読み方）#

ここから SELinux に入ります。第2巻で AlmaLinux を Enforcing のまま構築してきたので、本書ラボの 9 VM はすべて有効な状態です。まず現状を読みます。

実行コマンド（k8s-wl-02 上・developer）：

$ getenforce

実行結果：

Enforcing

実行コマンド（k8s-wl-02 上・developer）：

$ sudo sestatus

実行結果：

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

読むべき行は 3 つです。SELinux status: enabled（機能が有効）、Current mode: enforcing（違反を遮断する）、Mode from config file: enforcing（再起動後も enforcing）。この 3 つが揃って初めて「保護が働いている」と言えます。

3 つ目が重要なのは、setenforce 0 による変更が再起動で元に戻るからです。「動かないから setenforce 0 して直った」という対処は、次の再起動で再発します。しかもその間、原因は記録されていません。

Permissive は「ポリシーを作り込む途中で、何が拒否されるかを一通り集める」ための一時的な状態です。恒久的にそこへ置くのは、SELinux を切っているのと保護の面では同じです。

ラベルの四層構造#

SELinux はプロセスにもファイルにもラベルを付け、その組み合わせで可否を決めます。まずプロセス側を見ます。

実行コマンド（k8s-wl-02 上・developer）：

$ ps -eZ | grep -E "containerd|kubelet"

実行結果（抜粋）：

system_u:system_r:container_runtime_t:s0        containerd
system_u:system_r:kubelet_t:s0-s0:c0.c1023      kubelet

次にファイル側です。ls -Z でラベルが出ます。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo ls -Zd /etc/kubernetes /var/lib/containerd /var/lib/kubelet /var/lib/longhorn

実行結果（ls は引数の順ではなくソート順で出力します。ラベル列は右揃えになるため /etc/kubernetes の行だけ先頭が字下げされて見えます）：

  system_u:object_r:kubernetes_file_t:s0 /etc/kubernetes
system_u:object_r:container_var_lib_t:s0 /var/lib/containerd
system_u:object_r:container_var_lib_t:s0 /var/lib/kubelet
system_u:object_r:container_var_lib_t:s0 /var/lib/longhorn

ラベルは user:role:type:level の 4 つ組です。

判定に効くのは主に type です。プロセスの type とオブジェクトの type の組み合わせがポリシーで許可されているかどうかで、通るか弾かれるかが決まります。この仕組みを type enforcement と呼びます。

末尾の level（MCS）は、同じ type どうしの分離に使います。container_t のコンテナが 2 つあっても、カテゴリが c9,c240 と c337,c338 のように違えば互いのファイルを読めません。この性質は第10回のマルチテナンシー分離につながります。

なお /var/lib/longhorn が container_var_lib_t になっている点は、次節以降で扱う CSI ボリュームの自動リラベルへの伏線です。

Enforcing なのにコンテナは拘束されていない#

本回の核心です。ホストが Enforcing であることと、コンテナが SELinux で拘束されていることは別問題です。手元のクラスタで確かめます。

実行コマンド（k8s-wl-02 上・developer）：

$ ps -eZ | grep calico-node

実行結果：

system_u:system_r:spc_t:s0        39859 ?        00:00:00 calico-node
system_u:system_r:spc_t:s0        39862 ?        00:00:32 calico-node
system_u:system_r:spc_t:s0        39863 ?        00:00:00 calico-node

1 つのコンテナだけを見ても全体は分かりません。ノード上の全プロセスを type 別に集計します。

実行コマンド（k8s-wl-02 上・developer）：

$ ps -eZ | cut -d" " -f1 | cut -d: -f3 | sort | uniq -c | sort -rn | head

実行結果（プロセス数は起動のたびに変わります。本書ラボでも別の起動では 137 kernel_t / 10 unconfined_t になりました。見るのは絶対数ではなく「spc_t が並び、container_t が 1 つも無い」という並びです）：

    139 kernel_t
     96 spc_t
     16 container_runtime_t
     11 unconfined_t

原因は containerd の設定#

コンテナに SELinux ラベルを割り当てるのはコンテナランタイムの仕事です。containerd 側でその機能が無効なら、kubelet が渡す SELinux 情報は使われません。

Workload Node には crictl が入っていません（第2巻第15回で 3 台の Control Plane Node にのみ導入しました）。そこで containerd config dump で実効値を読みます。設定ファイルではなく、containerd が実際に採用している値が出ます。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo containerd config dump | grep -i selinux

実行結果：

    enable_selinux = false
    selinux_category_range = 1024

containerd v2 の既定は enable_selinux = false です。 この状態では、コンテナは spc_t で起動します。つまり seLinuxOptions を Pod に書いても効かず、後述する kubelet の自動リラベルも起きません。SELinux 関連の Pod 設定がすべて無効化されていると考えてください。

selinux_category_range = 1024 は、MCS カテゴリを何個の範囲から払い出すかの設定です。有効化した後に c9,c240 のような値が出てくるのはこの範囲からの割り当てです。

「拒否が出ていない」ことの意味#

構図をはっきりさせるために、Control Plane Node のファイルラベルを見ます。

実行コマンド（k8s-cp-01 上・developer）：

$ ls -Zd /var/lib/etcd

実行結果：

unconfined_u:object_r:var_lib_t:s0    /var/lib/etcd

コンテナ用の type（container_var_lib_t や container_file_t）ではなく、汎用の var_lib_t です。それでも etcd コンテナが読み書きできているのは、そのプロセスが spc_t だからにほかなりません。拘束されていないので、ラベルが噛み合っていなくても通ってしまいます。

第2回で kube-bench を回したとき、SELinux 関連の項目は FAIL になりませんでした。CIS Benchmark が見るのは「ホストの SELinux が有効か」までだからです。コンテナが spc_t で動いているかどうかは検査項目にありません。

第5回でも「ベンチマークが通ることと安全であることは別」という論点が出ました。本回はそれを SELinux で、しかも数値ではなくプロセスラベルという形で確認しています。ベンチマークは出発点であって到達点ではありません。

Kubernetes から SELinux を操作する 2 つの入口#

コンテナを container_t で動かせるようになったとき、Pod 側から指定できるのは何かを整理します。先に誤解を 1 つ潰しておきます。

Kubernetes での入口は 2 つです。

seLinuxOptions は次のように書きます。

spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c100,c200"

4 つ組のうち user / role / type / level を個別に指定できます。実務で書くことが多いのは level（MCS カテゴリの固定）です。type を変えるのは、専用のポリシーモジュールを用意している場合に限られます。

自動リラベルの対象と対象外#

次の Pod で、プロセスとボリュームの実体を実測しました（YAML 全量）。

apiVersion: v1
kind: Pod
metadata:
  name: selinux-level-test
spec:
  nodeName: k8s-wl-02
  securityContext:
    seLinuxOptions:
      level: "s0:c100,c200"
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]
    volumeMounts:
    - name: scratch
      mountPath: /scratch
    - name: hostdir
      mountPath: /hostdir
  volumes:
  - name: scratch
    emptyDir: {}
  - name: hostdir
    hostPath:
      path: /opt
      type: Directory

結果は次のとおりです。

自動リラベルの対象になるのは emptyDir / Secret / ConfigMap / SELinux マウントに対応した CSI ドライバです。本書ラボの Longhorn は CSI 側で対応しているので、やってみよう① で db-0 を作り直したときにマウント点がリラベルされます。

hostPath は対象外です。ホストのディレクトリをそのまま見せる仕組みなので、kubelet が勝手にラベルを書き換えるとホスト側の他の利用者に影響が出ます。必要ならホスト側で chcon / semanage fcontext するしかありません。やってみよう② はこのケースを扱います。

level を指定しないとどうなるか#

seLinuxOptions を書かない場合、kubelet と containerd が Pod ごとにランダムな MCS カテゴリ 2 つを払い出します。実測では s0:c9,c240 や s0:c337,c338 のような値になりました。

これにより、同じ container_t どうしでも Pod 間でファイルを覗けません。type が同じでもカテゴリが違えば通らないという MCS の性質が、Pod 単位の分離としてそのまま使われています。何も書かなくても分離が効くのはこのためです。

あえて明示指定するのは、テナントごとにカテゴリを固定したいような場合です。同じテナントの Pod どうしは共有させ、別テナントとは分ける、という設計ができます。この使い方は第10回のマルチテナンシー分離で扱います。

AppArmor（記法と、非対応ノードでの挙動）#

AppArmor は、プロファイルでプロセスのファイルアクセス・capability・ネットワーク等を制限する LSM です。SELinux がラベルで判定するのに対し、AppArmor はパスで判定するのが大きな違いです。Ubuntu / Debian 系では既定で有効ですが、RHEL 系（AlmaLinux）はカーネルが SELinux のみを LSM として組み込んでいます。

最も明快な証拠#

実行コマンド（k8s-wl-02 上・developer）：

$ cat /sys/kernel/security/lsm

実行結果（AlmaLinux 10.2）：

lockdown,capability,yama,selinux,bpf,landlock,ima,evm

apparmor が含まれていません。 Ubuntu なら同じファイルに apparmor が並びます。カーネルに組み込まれていない以上、パッケージを入れても Pod に指定しても動きません。この 1 行が、AppArmor が使えるかどうかの最短の判定方法です。

新フィールド記法（v1.31 GA 以降の正式）#

securityContext:
  appArmorProfile:
    type: Localhost
    localhostProfile: k8s-apparmor-example-deny-write

seccomp と同じ 3 種類ですが、localhostProfile に書くのはファイルパスではなくプロファイル名である点が違います。seccomp は /var/lib/kubelet/seccomp/ からの相対パス、AppArmor は apparmor_parser でロード済みのプロファイル名です。この非対称は試験でも間違えやすい箇所なので、並べて覚えてください。

旧アノテーション記法（v1.30 で非推奨）#

container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>

アノテーションなので metadata.annotations に書き、コンテナ名をキーに含めるのが特徴です。値の localhost/ という接頭辞も新記法にはありません。既存のマニフェストや古い教材にはこちらが出てくるので、新旧の対比は CKS でも問われ得ます。新規に書くときは新フィールド記法を使ってください。

Killer.sh（Ubuntu）で行う実機演習#

AlmaLinux ラボではプロファイルを適用できないので、プロファイルの作成とロードは Ubuntu 環境で行ってください。手順の形は次の 4 段です。予習として頭に入れておくと、Killer.sh で迷いません。

1. プロファイルを Workload Node にロードする（apparmor_parser -q /etc/apparmor.d/<profile>）
2. ロード済みであることを確認する（aa-status または cat /sys/kernel/security/apparmor/profiles）
3. Pod に appArmorProfile（type: Localhost + プロファイル名）を指定する
4. プロファイルが禁止する操作がブロックされることを確認する

ロードが先で、Pod の投入が後です。未ロードのプロファイル名を指定すると Pod は起動しません。seccomp の Localhost でファイルを置き忘れたときと同じ構図で、こちらも「ノードごとのローカルな準備」が前提になります。

本書ラボでは、代わりに非対応ノードでの拒否のされ方を やってみよう⑤ で確認します。同じマニフェストが Ubuntu では通り、AlmaLinux では通らない。その差がどう表示されるかを知っておくことは、試験環境と手元環境を行き来する学習では実用的です。

やってみよう①：containerd の SELinux 連携を有効にする#

ステップ1：現状を確認する#

k8s-wl-01 と k8s-wl-02 の両方で確認します。3 点を揃えて見ておくと、後で「何が変わったか」を言葉にできます。

実行コマンド（k8s-wl-01 / k8s-wl-02 上・developer）：

$ getenforce
$ sudo containerd config dump | grep -i selinux
$ ps -eZ | grep calico-node

実行結果：

Enforcing
    enable_selinux = false
    selinux_category_range = 1024
system_u:system_r:spc_t:s0         4072 ?        00:00:08 calico-node
system_u:system_r:spc_t:s0         4074 ?        00:00:00 calico-node
system_u:system_r:spc_t:s0         4076 ?        00:00:00 calico-node

Enforcing / enable_selinux = false / spc_t の 3 点セットです。「ホストは守られているのにコンテナは拘束されていない」という状態が、この 3 行に集約されています。

ステップ2：設定を書き換える#

k8s-wl-01 と k8s-wl-02 の両方で行います。まずバックアップを取ってから sed で 1 行だけ差し替えます。

実行コマンド（k8s-wl-01 / k8s-wl-02 上・developer）：

$ sudo cp /etc/containerd/config.toml /etc/containerd/config.toml.bak-06
$ sudo sed -i 's/^    enable_selinux = false/    enable_selinux = true/' /etc/containerd/config.toml
$ sudo containerd config dump | grep -i selinux

実行結果：

    enable_selinux = true
    selinux_category_range = 1024

sed ではなくエディタで直す場合は、/etc/containerd/config.toml を vi で開き、[plugins.'io.containerd.cri.v1.runtime'] セクションの直下にある行を書き換えます。本書ラボでは 59 行目付近です。

  [plugins.'io.containerd.cri.v1.runtime']
    enable_selinux = true
    selinux_category_range = 1024

ステップ3：containerd を再起動する#

設定ファイルを書き換えただけでは containerd は読み直しません。k8s-wl-01 と k8s-wl-02 の両方で再起動します。

実行コマンド（k8s-wl-01 / k8s-wl-02 上・developer）：

$ sudo systemctl restart containerd
$ systemctl is-active containerd kubelet

実行結果：

active
active

この構造のおかげで、containerd を再起動しても既存のコンテナは巻き添えになりません。実際に数えてみます。

実行コマンド（k8s-wl-02 上・developer）：

$ pgrep -c containerd-shim

実行結果（k8s-wl-02 の場合。数そのものはノードに載っているコンテナの数で決まるので、k8s-wl-01 では別の値になります。本書ラボの実測は wl-02 が 15、wl-01 が 50 でした）：

15

ここを理解していないと、次の 2 つで判断を誤ります。1 つは「設定したのに ps -eZ が spc_t のままだ、失敗した」と早合点すること。もう 1 つは、本番で「再起動してもコンテナが落ちないなら無停止で入れられる」と考えて、実際には Pod を作り直すまで効果が無いことを見落とすことです。

ステップ4：Pod を作り直してラベルの変化を見る#

素の Pod を 1 つ作って確認します。nodeName を必ず指定してください。 有効化したノードに載らないと container_t にはなりません。

se-test.yaml（k8s-ops 上で作成）：

apiVersion: v1
kind: Pod
metadata:
  name: se-test
spec:
  nodeName: k8s-wl-02
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]

実行コマンド（k8s-ops 上・developer）：

$ kubectl apply -f se-test.yaml
$ kubectl get pod se-test -o wide

実行結果：

pod/se-test created
NAME      READY   STATUS    RESTARTS   AGE   IP              NODE        NOMINATED NODE   READINESS GATES
se-test   1/1     Running   0          15s   10.244.119.130   k8s-wl-02   <none>           <none>

ノード側でプロセスのラベルを読みます。

実行コマンド（k8s-wl-02 上・developer）：

$ ps -eZ | grep -E "sleep|pause" | grep container_t

実行結果：

system_u:system_r:container_t:s0:c168,c271 21193 ? 00:00:00 pause
system_u:system_r:container_t:s0:c168,c271 21225 ? 00:00:00 sleep

container_t + Pod ごとのランダムな MCS カテゴリ 2 つで起動しました。カテゴリの値（ここでは c168,c271）は Pod を作るたびに変わるので、手元では別の数字になります。pause（Pod のインフラコンテナ）と sleep（アプリのプロセス）が同じカテゴリである点を確認してください。カテゴリの払い出し単位が Pod であることが、ここでも確認できます。

後片付けをします。

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod se-test

ステップ5：既存ワークロードを作り直して壊れないことを確かめる#

設定を入れただけで終わらせないのが本番の作法です。DaemonSet・StatefulSet・Deployment を代表的に作り直し、container_t になっても動くことを確認します。

手順 2 の待ち時間は、本書ラボの実測で 10 秒ほどでした。Longhorn のボリュームは同じノードへ付け直されるだけなので短時間で済みます。ContainerCreating が数分続く場合は Longhorn 側のアタッチが滞っているので、kubectl describe pod fanclub-db-0 -n fanclub の Events を確認してください。

まず、privileged な DaemonSet が container_t にならないことを先に確かめます。

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod -n kube-system -l k8s-app=calico-node --field-selector spec.nodeName=k8s-wl-02
$ kubectl delete pod -n fanclub -l app=fanclub-logcollector --field-selector spec.nodeName=k8s-wl-02

どちらも DaemonSet なので、削除するとすぐ同じノードに作り直されます。1 分ほど待ってからノード側でラベルを見ます。

実行コマンド（k8s-wl-02 上・developer）：

$ ps -eZ | grep calico-node
$ ps -eZ | grep container_t | grep sleep

実行結果（pid は作り直すたびに変わります。見るのは 1 列目の type だけです）：

system_u:system_r:spc_t:s0        82674 ?        00:00:00 calico-node
system_u:system_r:spc_t:s0        82675 ?        00:00:01 calico-node
system_u:system_r:spc_t:s0        82677 ?        00:00:00 calico-node

system_u:system_r:container_t:s0:c10,c875 83681 ? 00:00:00 sleep

作り直したのに calico-node は spc_t のままです。privileged: true のコンテナはランタイムが意図的に spc_t で起動するためで、SELinux で封じ込める対象から外れます。一方 fanclub-logcollector（busybox で sleep しているだけの DaemonSet）は container_t になりました。「有効化すれば全部拘束される」わけではないことを、ここで押さえてください。

次に db-0 を作り直します。

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod fanclub-db-0 -n fanclub
$ kubectl get pod fanclub-db-0 -n fanclub -w

1/1 Running になったら Ctrl+C で -w を抜け、backend と frontend を作り直します。

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod -n fanclub -l app=fanclub-backend
$ kubectl delete pod -n fanclub -l app=fanclub-frontend
$ kubectl get pod -n fanclub -o wide

作り直した結果を、対象ごとに表で整理します。

ノード側でラベルを確認します。

実行コマンド（k8s-wl-01 上・developer）：

$ ps -eZ | grep -E "java|nginx" | grep container_t

実行結果：

system_u:system_r:container_t:s0:c143,c590 35715 ? 00:00:23 java
system_u:system_r:container_t:s0:c49,c769 35838 ? 00:00:00 nginx
system_u:system_r:container_t:s0:c49,c769 35879 ? 00:00:00 nginx
system_u:system_r:container_t:s0:c49,c769 35880 ? 00:00:00 nginx
system_u:system_r:container_t:s0:c49,c769 35881 ? 00:00:00 nginx
system_u:system_r:container_t:s0:c49,c769 35882 ? 00:00:00 nginx

nginx は master と worker で複数プロセスに分かれますが、同じ Pod なのでカテゴリは全部同じです。サイドカーも同じ Pod のカテゴリを共有します。

実行コマンド（k8s-wl-01 上・developer）：

$ ps -eZ | grep -E "tail|java" | grep container_t

実行結果：

system_u:system_r:container_t:s0:c143,c590 35664 ? 00:00:00 tail
system_u:system_r:container_t:s0:c143,c590 35715 ? 00:00:23 java

emptyDir が自動リラベルされていることも確認できます。

実行コマンド（k8s-wl-01 上・developer）：

$ sudo find /var/lib/kubelet/pods -maxdepth 4 -type d -path "*/volumes/*" -name payara-tmp -exec ls -Zd {} \;

実行結果（Pod の UID は環境ごとに異なります）：

system_u:object_r:container_file_t:s0:c143,c590 /var/lib/kubelet/pods/938e7b78-7496-4707-9b1c-60f8efb79c1d/volumes/kubernetes.io~empty-dir/payara-tmp

配下の runtime / lib / docroot / config まで再帰的にリラベルされています。サイドカーと共有している applog の emptyDir も同じ c143,c590 です（-name applog に変えて同じコマンドを打つと確認できます）。Pod 単位でカテゴリが払い出されることが、ここでも確認できます。

Longhorn の CSI ボリュームを使っている db-0 も見ておきます。

実行コマンド（k8s-wl-02 上・developer）：

$ ps -eZ | grep postgres | head -1

実行結果：

system_u:system_r:container_t:s0:c151,c177 23055 ? 00:00:00 postgres

マウント点も見ておきます。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo find /var/lib/kubelet/pods -maxdepth 6 -type d -path "*/volumes/kubernetes.io~csi/*" -name mount -exec ls -Zd {} \;

実行結果（db-0 のボリュームだけが postgres と同じカテゴリになっています。有効化する前に作られた他のボリュームは unlabeled_t のままです）：

system_u:object_r:container_file_t:s0:c151,c177 /var/lib/kubelet/pods/.../volumes/kubernetes.io~csi/pvc-226c8f31-f346-4327-aec7-4f3f39707a4b/mount
system_u:object_r:unlabeled_t:s0 /var/lib/kubelet/pods/.../volumes/kubernetes.io~csi/pvc-21281d08-c435-4033-a67d-c95bce442936/mount

マウント点も同じカテゴリへ自動リラベルされています（container_file_t:s0:c151,c177）。「対応した CSI ドライバなら自動リラベルの対象になる」という説明が、Longhorn で成立していることの実証です。hostPath だけが対象外という切り分けを、ここで再確認してください。

ステップ5 の冒頭で確認したとおり、calico-node は有効化した後に作り直しても spc_t のままでした。

privileged: true のコンテナは confine されない——seccomp の節で書いたのと同じ性質です。CNI やストレージのエージェントのように privileged が要る DaemonSet は、SELinux でも seccomp でも拘束できません。それらは「拘束できないもの」として把握し、別の層（イメージの出所・RBAC・NetworkPolicy）で守る対象に回します。

最後に HTTPS が返ることを確認します。

実行コマンド（k8s-ops 上・developer）：

$ curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://fanclub.local/

実行結果：

200

k8s-ops からは --noproxy '*' が必須です。付け忘れると Squid 経由になり 000 が返ります。第5回で確定した作法です。

ステップ6：本番ではどうするか#

「1 台ずつ手で直した設定が、ノード追加とパッケージ更新の 2 経路で失われる」という構図は、やってみよう④ の Localhost seccomp プロファイルでも同じ形で出てきます。ノードローカルな設定は構成管理に載せる——本回で 2 度出てくる論点です。

やってみよう②：拒否を意図的に起こして AVC を読み解く#

やってみよう① でコンテナを container_t にしました。拘束が効いているということは、これまで通っていた操作が拒否され得るということでもあります。その拒否をどう読み、どう直すかが本節です。対象は k8s-wl-02 です。

ステップ0：道具を入れる#

永続的なラベル設定に使う semanage は、AlmaLinux 10.2 の既定では入っていません。chcon / restorecon / ausearch / semodule は導入済みです。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo dnf install -y policycoreutils-python-utils
$ command -v semanage

実行結果（末尾）：

/usr/sbin/semanage

なお setroubleshoot-server（journalctl -t setroubleshoot で人間向けの解説を出すツール）は入れません。本回で必要な情報は ausearch の生の AVC で足ります。ノードに入れるパッケージは少ないほどよく、これは第7回で扱う攻撃面削減の考え方と同じです。「便利だから入れる」ではなく「必要だから入れる」で判断してください。

前半：拒否を起こして AVC を読む#

ステップ1：ホスト側に検証用ディレクトリを作る#

実行コマンド（k8s-wl-02 上・developer）：

$ sudo mkdir -p /opt/se-demo
$ echo "top-secret-data" | sudo tee /opt/se-demo/secret.txt
$ ls -Zd /opt/se-demo
$ ls -Z /opt/se-demo/secret.txt

実行結果（末尾 2 行）：

unconfined_u:object_r:usr_t:s0 /opt/se-demo
unconfined_u:object_r:usr_t:s0 /opt/se-demo/secret.txt

/opt 配下なので既定ラベルは usr_t です。何も細工していない、ごく普通のディレクトリである点を押さえてください。この後で起きる拒否は、特別な仕掛けの結果ではありません。

ステップ2：hostPath でマウントした Pod から読んでみる#

sedeny-test.yaml（k8s-ops 上で作成）：

apiVersion: v1
kind: Pod
metadata:
  name: sedeny-test
spec:
  nodeName: k8s-wl-02
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]
    volumeMounts:
    - name: demo
      mountPath: /data
  volumes:
  - name: demo
    hostPath:
      path: /opt/se-demo
      type: Directory

実行コマンド（k8s-ops 上・developer）：

$ kubectl apply -f sedeny-test.yaml
$ kubectl exec sedeny-test -- cat /data/secret.txt

実行結果：

pod/sedeny-test created
top-secret-data

ステップ3：書いてみる#

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec sedeny-test -- sh -c 'echo x > /data/w.txt'

実行結果：

sh: can't create /data/w.txt: Permission denied
command terminated with exit code 1

拒否されました。ここで注意したいのは、Permission denied という文言だけでは SELinux が原因だと分からない点です。通常のパーミッション（rwx）でも同じメッセージが出ます。ls -l で権限を見て問題が無いのに拒否される、というときに AVC を疑います。

ステップ4：AVC を読む#

実行コマンド（k8s-wl-02 上・developer）：

$ sudo ausearch --input-logs -m AVC -ts recent

実行結果（該当部分）：

type=AVC msg=audit(1785106053.092:1132): avc:  denied  { write } for  pid=33621 comm="sh"
  name="se-demo" dev="dm-0" ino=68106886
  scontext=system_u:system_r:container_t:s0:c486,c575
  tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir permissive=0

1 行ずつ読みます。この 6 要素だけ押さえれば、AVC はほぼ読めます。

この 1 行から言えることは、「container_t のプロセスが、usr_t のディレクトリに書こうとして遮断された」です。直すべき対象は tcontext と tclass が指しています——ディレクトリ（dir）のラベル（usr_t）です。ファイルのラベルを直しても、この拒否は消えません。

後半：AVC に出ない拒否と、恒久的な対処#

ステップ5：AVC に出ない拒否を確認する（dontaudit）#

今度は読み取りを拒否させます。ファイルのラベルを、コンテナに許可されていない type に変えます。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo chcon -t admin_home_t /opt/se-demo/secret.txt
$ ls -Z /opt/se-demo/secret.txt

実行結果：

unconfined_u:object_r:admin_home_t:s0 /opt/se-demo/secret.txt

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec sedeny-test -- cat /data/secret.txt

実行結果：

cat: can't open '/data/secret.txt': Permission denied
command terminated with exit code 1

期待どおり拒否されました。では AVC を見ます。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo ausearch --input-logs -m AVC -ts recent

実行結果（ステップ4 の write の 1 件しか出ません。read の拒否は記録されていません）：

type=AVC msg=audit(1785106053.092:1132): avc:  denied  { write } for  pid=33621 comm="sh"
  name="se-demo" dev="dm-0" ino=68106886
  scontext=system_u:system_r:container_t:s0:c486,c575
  tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir permissive=0

一時的に無効化して、同じ操作をやり直します。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo semodule -DB

実測で 6 秒ほどかかりました。ポリシーを再構築しているので、瞬時には終わりません。

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec sedeny-test -- cat /data/secret.txt

実行結果（拒否されるのは同じです）：

cat: can't open '/data/secret.txt': Permission denied
command terminated with exit code 1

実行コマンド（k8s-wl-02 上・developer）：

$ sudo ausearch --input-logs -m AVC -ts recent

実行結果（今度は read の拒否が記録されています）：

type=AVC msg=audit(1785106098.499:1261): avc:  denied  { read } for  pid=34729 comm="cat"
  name="secret.txt" dev="dm-0" ino=68132881
  scontext=system_u:system_r:container_t:s0:c486,c575
  tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

先ほどとの違いは tcontext が admin_home_t、tclass が file である点です。直す対象がファイル単体だと、この 1 行から分かります。

確認が済んだら必ず戻します。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo semodule -B

ステップ6：正しい対処でアクセスできるようにする#

まず一時的な修正です。chcon でファイルのラベルをコンテナ用の type に変えます。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo chcon -t container_file_t /opt/se-demo/secret.txt

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec sedeny-test -- cat /data/secret.txt

実行結果：

top-secret-data

読めるようになりました。ただしディレクトリへの書き込みは依然として拒否されます。直したのはファイルのラベルだけで、ディレクトリはまだ usr_t だからです。

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec sedeny-test -- sh -c 'echo x > /data/w.txt'

実行結果：

sh: can't create /data/w.txt: Permission denied
command terminated with exit code 1

これが AVC の tcontext と tclass を見て、どのオブジェクトを直すかを決めることの実演です。tclass=file の拒否はファイルを直せば消え、tclass=dir の拒否はディレクトリを直さないと消えません。「とりあえず全部 container_file_t にする」ではなく、拒否ログが指している対象だけを直すのが最小権限の考え方です。

永続的な修正を行います。ディレクトリ配下すべてを対象にします。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo semanage fcontext -a -t container_file_t '/opt/se-demo(/.*)?'
$ sudo restorecon -Rv /opt/se-demo
$ ls -Zd /opt/se-demo

実行結果：

Relabeled /opt/se-demo from unconfined_u:object_r:usr_t:s0 to unconfined_u:object_r:container_file_t:s0
/opt/se-demo/secret.txt not reset as customized by admin to unconfined_u:object_r:container_file_t:s0
unconfined_u:object_r:container_file_t:s0 /opt/se-demo

2 行目に注目してください。ステップ6 の前半で chcon を打った secret.txt は「管理者が手で変更したもの」と見なされ、restorecon の対象から外されます。今回は結果的に同じ type なので実害はありませんが、chcon で場当たり的に直したファイルが後の restorecon で揃わない、という食い違いの原因になります。chcon を打ったら restorecon -F（強制）で揃え直すか、最初から semanage fcontext で登録するのが確実です。

'/opt/se-demo(/.*)?' は正規表現で「このディレクトリ自身と、その配下すべて」を意味します。semanage fcontext -a がポリシーへの登録、restorecon が登録内容を実ファイルへ反映する、という 2 段構えです。片方だけでは効きません。

これで書き込みも通ります。

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec sedeny-test -- sh -c 'echo x > /data/w.txt && cat /data/w.txt'

実行結果：

x

ステップ7：後片付け#

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod sedeny-test

実行コマンド（k8s-wl-02 上・developer）：

$ sudo semanage fcontext -d '/opt/se-demo(/.*)?'
$ sudo rm -rf /opt/se-demo

semanage fcontext -d を忘れると、ディレクトリを消してもポリシーに登録が残ります。 残っていても直ちに害はありませんが、semanage fcontext -l -C（ローカル定義の一覧）にゴミが溜まります。演習用の登録は消してください。あわせて semodule -B を打ち忘れていないかも、ここで確認しておきます。

やってみよう③：fanclub-backend に seccomp を入れる（GitOps 経由）#

ここまでは検証用の Pod で確認してきました。ここからは実際に動いているアプリケーションに手を入れます。

ステップ1：現状を測る#

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec -n fanclub deploy/fanclub-backend -c backend -- grep -E "Seccomp|NoNewPrivs" /proc/1/status

実行結果：

NoNewPrivs:	1
Seccomp:	0
Seccomp_filters:	0

NoNewPrivs: 1 は allowPrivilegeEscalation: false の効果です。第1巻で入れた設定が実際にプロセスへ届いていることが読めます。一方で Seccomp: 0——syscall フィルタは掛かっていません。ここを 2 にするのが本節の目的です。

ステップ2：変更してよい場所を先に確かめる#

fanclub は第2巻第14回で ArgoCD の管理下に入っています。手を付ける前に、対象が管理対象かどうかを確認します。

実行コマンド（k8s-ops 上・developer）：

$ kubectl get application fanclub-api-prod -n argocd -o jsonpath='{.spec.syncPolicy}'

実行結果：

{"automated":{"prune":true,"selfHeal":true}}

実行コマンド（k8s-ops 上・developer）：

$ kubectl get application fanclub-api-prod -n argocd -o jsonpath='{range .status.resources[*]}{.kind}{"/"}{.name}{"\n"}{end}'

実行結果：

ConfigMap/fanclub-config
ConfigMap/fanclub-db-init
ConfigMap/fanclub-frontend-config
ResourceQuota/fanclub-quota
Service/fanclub-backend
Service/fanclub-frontend
Deployment/fanclub-backend
Deployment/fanclub-frontend

selfHeal: true であり、管理対象 8 リソースに Deployment/fanclub-backend が含まれています。

ステップ3：Git を直す#

k8s-ops 上の ~/gitops/gitops-fanclub/base/backend-deployment.yaml を編集します。spec.template.spec にPod レベルで securityContext を追加します。

編集後の該当箇所（initContainers の直前に 3 行を挿入します）：

    spec:
      serviceAccountName: fanclub-backend
      automountServiceAccountToken: false
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      initContainers:

Pod レベルとコンテナレベルの関係を整理すると次のようになります。

fanclub-backend の場合、backend コンテナには既にコンテナレベルの securityContext がありますが、そこに seccompProfile は書かれていません。キー単位で上書きされるので、Pod レベルの seccompProfile は backend にも継承されます。capabilities.drop: [ALL] などの既存設定はそのまま残ります。

ステップ4：commit して push し、同期を待つ#

実行コマンド（k8s-ops 上・developer）：

$ cd ~/gitops/gitops-fanclub
$ git add base/backend-deployment.yaml
$ git commit -m "Add RuntimeDefault seccomp profile at pod level"
$ git push

fatal: unable to access 'http://k8s-registry:3000/developer/gitops-fanclub.git/': The requested URL returned error: 403

$ export no_proxy="$no_proxy,k8s-registry"
$ export NO_PROXY="$no_proxy"
$ git push

push が通ったら同期を待ちます。自動 sync は既定ポーリング任せで、本書ラボの実測では約 80 秒でした（ポーリング間隔の都合で最大 3 分ほどかかることもあります）。待てない場合は手動で同期できます。

実行コマンド（k8s-ops 上・developer）：

$ argocd app sync fanclub-api-prod
$ kubectl get pod -n fanclub -l app=fanclub-backend -w

Deployment の spec.template が変わるので、ArgoCD が同期した時点でローリング更新が走ります。3 本の Pod が順に置き換わり、それぞれ 2/2 Running になるまで待ってください。Pod が作り直されるからこそ seccomp が掛かる——やってみよう① で確認した「設定は次に作るコンテナから効く」と同じ原則です。

この chart は maxUnavailable: 0 で、backend の startupProbe が Payara の起動を待つため、3 本すべての入れ替えに 9 分ほどかかります。完了を確実に待つには次のコマンドを使います。

実行コマンド（k8s-ops 上・developer）：

$ kubectl rollout status deploy/fanclub-backend -n fanclub --timeout=600s

実行結果（末尾）：

deployment "fanclub-backend" successfully rolled out

ステップ5：効いたことを確認する#

本体コンテナとサイドカーの両方を確認します。Pod レベルに置いた効果を測るのが目的なので、片方だけでは足りません。

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec -n fanclub deploy/fanclub-backend -c backend -- grep -E "Seccomp|NoNewPrivs" /proc/1/status
$ kubectl exec -n fanclub deploy/fanclub-backend -c log-shipper -- grep -E "Seccomp|NoNewPrivs" /proc/1/status

実行結果（上 3 行が backend、空行をはさんで下 3 行が log-shipper）：

NoNewPrivs:	1
Seccomp:	2
Seccomp_filters:	1

NoNewPrivs:	0
Seccomp:	2
Seccomp_filters:	1

NoNewPrivs の値が違う点にも注目してください。backend は 1、log-shipper は 0 です。allowPrivilegeEscalation: false は backend のコンテナレベルにしか書かれていないため、サイドカーには効いていません。Pod レベルに置いた seccompProfile だけが両方に届いている——この 1 画面が、置き場所の違いをそのまま示しています。第8回で PSS Restricted を適用するときは、allowPrivilegeEscalation: false を log-shipper と wait-for-db にも 1 つずつ書き足す必要があります。このフィールドは Pod レベルに存在しないので、seccompProfile のようにまとめて継承させることはできません。

両方で Seccomp: 2 になっていれば、Pod レベルに置いた狙いどおりです。もし log-shipper が 0 のままなら、コンテナレベルに書いてしまっていないかを確認してください。

ステップ6：アプリが壊れていないことを確認する#

seccomp は syscall を止める仕組みなので、アプリが必要とする syscall を塞いでいないかを必ず確認します。RuntimeDefault は一般的なアプリで動くよう作られていますが、確認せずに本番へ入れる理由にはなりません。

実行コマンド（k8s-ops 上・developer）：

$ curl -sk --noproxy '*' -o /dev/null -w '%{http_code}\n' https://fanclub.local/
$ curl -sk --noproxy '*' https://fanclub.local/api/members

実行結果（1 行目が 1 本目の curl、2 行目以降が会員一覧の JSON）：

200
[{"createdAt":"2026-07-25T14:28:03.572932","email":"hanako@example.com","id":1,"name":"鈴木花子","plan":"standard"},{"createdAt":"2026-07-25T14:28:03.572932","email":"ichiro@example.com","id":2,"name":"佐藤一郎","plan":"free"},{"createdAt":"2026-07-25T18:00:53.008964","email":"restore-test@example.com","id":11,"name":"復元テスト太郎","plan":"premium"}]

k8s-ops からは --noproxy '*' が必須です（無いと Squid 経由で 000 になります）。第5回で確定した作法です。

既存の不変性が効いていることも、あわせて確認します。

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec -n fanclub deploy/fanclub-backend -c backend -- touch /test-file

実行結果：

touch: cannot touch '/test-file': Read-only file system
command terminated with exit code 1

ルートファイルシステムへの書き込みが弾かれるのは readOnlyRootFilesystem: true の効果で、これは第1巻第15回で入れたものです。seccomp を足しても既存の防御が外れていないことを、ここで確かめています。ハードニングは足し算なので、足したときに引き算が起きていないかを毎回見てください。

やってみよう④：Localhost seccomp プロファイルを配って適用する#

seccomp の節で記法だけ示した Localhost を、実際に通します。あわせて「配り忘れ」がどう見えるかも実演します。

ステップ1：まず k8s-wl-02 だけに置く#

/var/lib/kubelet/seccomp は既定では存在しません。mkdir -p から始めます。この時点では k8s-wl-01 には置きません（ステップ3 で配り忘れを実演するためです）。

実行コマンド（k8s-wl-02 上・developer）：

$ sudo mkdir -p /var/lib/kubelet/seccomp/profiles

/var/lib/kubelet/seccomp/profiles/deny-chmod.json を作成します。root 所有のディレクトリなので vi も sudo 付きで開いてください（sudo vi /var/lib/kubelet/seccomp/profiles/deny-chmod.json）。次の JSON を全量そのまま書きます。

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod", "fchmod", "fchmodat"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

読み方は 2 行だけです。defaultAction が SCMP_ACT_ALLOW（既定は許可）で、syscalls に列挙した syscall だけ SCMP_ACT_ERRNO（エラーを返す）にしています。chmod の系統を 3 つ並べているのは、同じ操作に複数の syscall があるためです。

SCMP_ACT_KILL と SCMP_ACT_KILL_PROCESS の違いは、マルチスレッドのアプリで効いてきます。fanclub-backend のような JVM アプリはスレッドを多数持つので、SCMP_ACT_KILL だと 1 スレッドだけが消えて、プロセスは中途半端な状態のまま生き残ります。止めたいなら SCMP_ACT_KILL_PROCESS を選んでください。

本番の最小化は逆に、SCMP_ACT_ERRNO を既定にして必要な syscall だけ許可します。ただしそれにはアプリが呼ぶ syscall を洗い出す作業が要ります。SCMP_ACT_LOG を既定にして一定期間動かし、ログから許可リストを作る、という進め方が現実的です。いきなり全部止めると起動すらしません。

置いたファイルのラベルを確認します。

実行コマンド（k8s-wl-02 上・developer）：

$ ls -Z /var/lib/kubelet/seccomp/profiles/deny-chmod.json

実行結果：

unconfined_u:object_r:container_var_lib_t:s0 /var/lib/kubelet/seccomp/profiles/deny-chmod.json

/var/lib/kubelet 配下なので container_var_lib_t が自動で付きます。ここに置く限り、ラベルを手で直す必要はありません。 もし別の場所に置いてシンボリックリンクを張ると、ラベルが噛み合わずに読めなくなることがあります。素直に規定のパスへ置いてください。

ステップ2：置いたノードの Pod に適用して拒否を確認する#

seccomp-local-test.yaml（k8s-ops 上で作成）：

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-local-test
spec:
  nodeName: k8s-wl-02
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/deny-chmod.json
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]

実行コマンド（k8s-ops 上・developer）：

$ kubectl apply -f seccomp-local-test.yaml
$ kubectl exec seccomp-local-test -- grep -E "Seccomp|NoNewPrivs" /proc/1/status

実行結果：

NoNewPrivs:	0
Seccomp:	2
Seccomp_filters:	1

フィルタが掛かりました。RuntimeDefault のときと同じ Seccomp: 2 です。/proc/1/status からは「どのプロファイルか」までは分かりません——実際に禁止した操作を試して確かめます。

実行コマンド（k8s-ops 上・developer）：

$ kubectl exec seccomp-local-test -- sh -c 'touch /tmp/f && chmod 777 /tmp/f'

実行結果：

chmod: /tmp/f: Operation not permitted
command terminated with exit code 1

touch は通り、chmod だけが弾かれました。 「全部止める」ではなく「特定の syscall だけ止める」という粒度が、実機で確認できます。SCMP_ACT_ERRNO なのでプロセスは死なず、chmod(2) がエラーを返しているだけです。

ステップ3：配っていないノードに載せてみる#

同じ localhostProfile を指定し、nodeName だけを k8s-wl-01 に変えた Pod を投入します。

seccomp-local-wl01.yaml（k8s-ops 上で作成）：

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-local-wl01
spec:
  nodeName: k8s-wl-01
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/deny-chmod.json
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]

実行コマンド（k8s-ops 上・developer）：

$ kubectl apply -f seccomp-local-wl01.yaml
$ kubectl get pod seccomp-local-wl01

実行結果：

NAME                 READY   STATUS                 RESTARTS   AGE
seccomp-local-wl01   0/1     CreateContainerError   0          30s

理由はイベントに出ます。

実行コマンド（k8s-ops 上・developer）：

$ kubectl describe pod seccomp-local-wl01

実行結果（Events 部分）：

  Type     Reason  Age               From     Message
  ----     ------  ----              ----     -------
  Normal   Pulled  2s (x5 over 30s)  kubelet  spec.containers{app}: Container image "busybox:1.37" already present on machine and can be accessed by the pod
  Warning  Failed  2s (x5 over 30s)  kubelet  spec.containers{app}: Error: failed to create containerd container: cannot load seccomp profile "/var/lib/kubelet/seccomp/profiles/deny-chmod.json": open /var/lib/kubelet/seccomp/profiles/deny-chmod.json: no such file or directory

seccomp の節で名前だけ示した CreateContainerError が、ここで実物として出ました。x5 over 30s から分かるとおり、kubelet はコンテナ作成を再試行し続けます。

status.phase も見ておきます。

実行コマンド（k8s-ops 上・developer）：

$ kubectl get pod seccomp-local-wl01 -o jsonpath='{.status.phase}'

実行結果：

Pending

STATUS 列は CreateContainerError、status.phase は Pending。この組み合わせは やってみよう⑤ の AppArmor と対比する材料になります。

ステップ4：k8s-wl-01 にも配って作り直す#

ステップ1 と同じ手順で deny-chmod.json を k8s-wl-01 に置きます。

実行コマンド（k8s-wl-01 上・developer）：

$ sudo mkdir -p /var/lib/kubelet/seccomp/profiles

同じ内容の deny-chmod.json を /var/lib/kubelet/seccomp/profiles/ に置いたら、Pod を作り直します。

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod seccomp-local-wl01
$ kubectl apply -f seccomp-local-wl01.yaml
$ kubectl get pod seccomp-local-wl01

実行結果：

NAME                 READY   STATUS    RESTARTS   AGE
seccomp-local-wl01   1/1     Running   0          6s

ステップ5：後片付け#

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod seccomp-local-test seccomp-local-wl01

実行コマンド（k8s-wl-01 / k8s-wl-02 上・developer）：

$ sudo rm -f /var/lib/kubelet/seccomp/profiles/deny-chmod.json

/var/lib/kubelet/seccomp/profiles ディレクトリは残しても害はありません。消す場合は rmdir で空であることを確認してから実行してください。他のプロファイルが同居している可能性があるので、rm -rf でディレクトリごと消さないでください。

やってみよう⑤：AppArmor 非対応ノードでの Pod 拒否を実機再現する#

「動かないこと」を実機で確かめる演習です。対象は k8s-wl-02 です。

ステップ1：ノードの LSM 対応状況を調べる#

実行コマンド（k8s-wl-02 上・developer）：

$ cat /sys/kernel/security/lsm
$ cat /sys/module/apparmor/parameters/enabled
$ cat /sys/kernel/security/apparmor/profiles
$ getenforce

実行結果：

lockdown,capability,yama,selinux,bpf,landlock,ima,evm
cat: /sys/module/apparmor/parameters/enabled: そのようなファイルやディレクトリはありません
cat: /sys/kernel/security/apparmor/profiles: そのようなファイルやディレクトリはありません
Enforcing

本書ラボは日本語ロケールです。英語ロケールの環境では No such file or directory と表示されます。

なお /sys/kernel/security/lsm は末尾に改行がありません。1 行目の直後にプロンプトや次の出力がそのまま続くので、画面では evm と次の行がつながって見えます。読みにくければ cat /sys/kernel/security/lsm; echo のように echo を足してください。

Ubuntu なら 2 番目が Y、3 番目にロード済みプロファイルの一覧が返ります。このノードの MAC は SELinux であって AppArmor ではないことが、この 4 行で確定します。

ステップ2：AppArmor プロファイルを要求する Pod を投入する#

apparmor-test.yaml（k8s-ops 上で作成）：

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-test
spec:
  nodeName: k8s-wl-02
  containers:
  - name: app
    image: busybox:1.37
    command: ["sleep", "3600"]
    securityContext:
      appArmorProfile:
        type: RuntimeDefault

実行コマンド（k8s-ops 上・developer）：

$ kubectl apply -f apparmor-test.yaml

ステップ3：拒否のされ方を観察する#

実行コマンド（k8s-ops 上・developer）：

$ kubectl get pod apparmor-test

実行結果：

NAME            READY   STATUS     RESTARTS   AGE
apparmor-test   0/1     AppArmor   0          25s

phase と reason と message を 1 行で読みます。

実行コマンド（k8s-ops 上・developer）：

$ kubectl get pod apparmor-test -o jsonpath='{.status.phase}|{.status.reason}|{.status.message}'

実行結果：

Failed|AppArmor|Pod was rejected: Cannot enforce AppArmor: AppArmor is not enabled on the host

Pod was rejected という文言が示すとおり、kubelet が admit（受け入れ）の段階で弾いています。コンテナ作成にすら進みません。イベントも 1 行だけです。

実行コマンド（k8s-ops 上・developer）：

$ kubectl describe pod apparmor-test

実行結果（Events 部分）：

  Type     Reason    Age   From     Message
  ----     ------    ----  ----     -------
  Warning  AppArmor  25s   kubelet  Cannot enforce AppArmor: AppArmor is not enabled on the host

seccomp の CreateContainerError が x5 over 30s と再試行していたのに対し、こちらは 1 回きりです。この違いも、admit で弾かれたかコンテナ作成で失敗したかの差から来ています。

ステップ4：試験環境との差分を理解する#

同じマニフェストが CKS 試験環境（Ubuntu）では通ります。なぜラボでは通らないのかを、LSM の観点で説明できるようにしてください。要点は 2 つです。

• AppArmor はカーネル機能である。ユーザー空間のパッケージを入れても、カーネルに組み込まれていなければ動かない
• コンテナはホストのカーネルを共有する。したがってコンテナイメージが Ubuntu であっても、ホストが AlmaLinux なら AppArmor は使えない

2 つ目は、SELinux にも同じことが言えます。MAC はイメージではなくノードの性質で決まります。 「イメージを Ubuntu にすれば AppArmor が使える」は誤りです。

本回で見た 2 つの失敗を並べて整理します。この表は試験の切り分けでそのまま使えます。

STATUS 列は phase そのものではなく、kubelet が付けた理由を優先して表示します。phase だけ見ても原因は分からないので、STATUS 列の固有名で当たりを付けるのが実務でも試験でも速い進め方です。AppArmor や CreateContainerError という文字列を見た瞬間に describe を打つ、という反射を作ってください。

ステップ5：後片付け#

実行コマンド（k8s-ops 上・developer）：

$ kubectl delete pod apparmor-test

Failed の Pod は自動では消えませんので、明示的に削除してください。放置すると kubectl get pod の一覧に残り続け、次の演習で紛らわしくなります。

なぜ Control Plane には入れないのか（実測に基づく境界）#

やってみよう① で enable_selinux = true にしたのは Workload Node 2 台だけでした。Control Plane Node 3 台を対象外にした理由を、実測とともに示します。「やらない」という判断にも根拠が要る——ここが本節の主題です。

同じ設定を Control Plane に入れると、次にコンテナが作り直されたタイミングで壊れます。検証環境（k8s-cp-03）で実際に確かめた結果です。

etcd が起動しなくなる#

etcd コンテナのログ（実測）：

{"level":"fatal","caller":"etcdmain/etcd.go:227","msg":"failed to list data directory",
 "dir":"/var/lib/etcd","error":"open /var/lib/etcd: permission denied"}

fatal なので即座に終了し、kubelet が作り直し、また落ちます。実測では 10 回以上 CrashLoop しました。

scheduler と controller-manager も落ちる#

AVC（実測）：

avc: denied { read } for pid=16899 comm="kube-scheduler" name="scheduler.conf"
  scontext=system_u:system_r:container_t:s0:c205,c830
  tcontext=unconfined_u:object_r:kubernetes_file_t:s0 tclass=file permissive=0

kube-controller-manager も同じ形で controller-manager.conf の read を拒否されました。やってみよう② で練習した AVC の読み方が、そのまま使えます。 scontext が container_t、tcontext が kubernetes_file_t、tclass が file——「拘束されたプロセスが、コンテナ用でない type のファイルを読もうとした」と読めます。

原因はラベルの不一致#

これまで動いていたのは、Control Plane のコンテナが spc_t だったからです。拘束を掛けた途端、噛み合っていなかったラベルが表に出ます。「今まで動いていたのに設定を変えたら壊れた」のではなく、「今まで検査していなかったものを検査し始めた」のです。

Control Plane で有効化するには、これらを semanage fcontext + restorecon でコンテナ用の type へ整える必要があります。技術的には可能です。しかし kubeadm が管理するパスに手を入れることになり、第5回で確立した「kubeadm クラスタではノード上のファイルは結果であって正本ではない」という原則とも衝突します。kubeadm upgrade がファイルを作り直したとき、ラベルがどうなるかまで面倒を見ることになります。

もし試してしまったら#

実行コマンド（誤って有効化してしまった Control Plane Node 上・developer）：

$ sudo sed -i 's/^    enable_selinux = true/    enable_selinux = false/' /etc/containerd/config.toml
$ sudo systemctl restart containerd
$ sudo containerd config dump | grep enable_selinux

本書は Control Plane に入れない手順なので、バックアップ（config.toml.bak-06）を取っていない前提で sed で直接戻しています。ホスト名も、どのノードで踏むかは分からないので固定していません。

実行結果：

    enable_selinux = false

実測では数十秒で etcd / kube-scheduler / kube-controller-manager / kube-apiserver が spc_t で自動復帰しました。復旧後は etcd の 3 エンドポイントとも health が true、ノードも 5/5 Ready に戻っています。

逆に言えば、正常稼働している Control Plane で enable_selinux = true にしても、その瞬間は何も起きません。壊れるのは次に static Pod が作り直されたとき——ノード再起動、kubelet 再起動、あるいは kubeadm upgrade のときです。設定変更とその影響が現れるタイミングが離れているため、原因追跡が難しくなります。これも Control Plane を対象外にする理由の 1 つです。

暗記必須コマンド（seccomp / SELinux / AppArmor）#

試験中は kubernetes.io/docs を含む許可された 8 サイトを参照できます。そこに載っているものは覚えなくてよく、載っていないものは覚える——この線引きで表を分けます。

appArmorProfile と seccompProfile の記法は kubernetes.io/docs に載っているので参照可能です。一方 SELinux 系のコマンド（semanage / semodule / ausearch / chcon / restorecon / setsebool）と apparmor_parser / aa-status は許可リスト外＝暗記対象です。ただし試験ホスト上の man は使えますので、オプションの細部まで覚える必要はありません。

この表で最も使う頻度が高いのは grep Seccomp /proc/1/status と ausearch --input-logs -m AVC -ts recent の 2 つです。前者は「入れた設定が届いているか」、後者は「何が止められたか」を答えてくれます。設定した後に必ず測るという手順を、この 2 コマンドで習慣にしてください。

暗記の優先順位も付けておきます。 表の SELinux 系 8 行は本書ラボの MAC が SELinux だから積む道具で、試験環境の MAC は AppArmor です。試験本番で最優先に暗記すべきは apparmor_parser / aa-status と seccomp の記法で、SELinux 系は「同じ型を別の道具でやる」ための理解として持っておく、という配分になります。

本文のコマンドは読みやすさのため kubectl と書いていますが、試験では alias k=kubectl が最初から設定されています（bash 補完も入っています）。本回のように kubectl exec と kubectl get pod を何度も往復する作業では、k で打つだけで所要時間が縮みます。第1回で用意した export do="--dry-run=client -o yaml" と合わせて、開始直後に手が動く状態を作ってください。

まとめ#

本回では次の点を確認しました。

• seccomp は syscall を絞る。RuntimeDefault を出発点にし、/proc/1/status の Seccomp: 2 で効果を確認する。privileged: true では無視される
• Localhost プロファイルは /var/lib/kubelet/seccomp/ 配下に置き、全 Workload Node に配る。無いノードに載った Pod は CreateContainerError で止まる
• capabilities は drop ALL してから必要分のみ add する。8080 番で待ち受けるなら NET_BIND_SERVICE も不要
• ホストが Enforcing でも、containerd の enable_selinux が false ならコンテナは spc_t で動き、拘束されない。 containerd config dump と ps -eZ で必ず確認する
• containerd の再起動では既存コンテナは落ちない。 shim がライフサイクルを持っているためで、設定はその後に作るコンテナから効く
• Kubernetes に :z / :Z は無い。kubelet が emptyDir / Secret / ConfigMap / 対応 CSI を自動リラベルし、hostPath は対象外
• 拒否が出たら ausearch -m AVC を読み、scontext / tcontext / tclass からどこを直すか決める。setenforce 0 は解決策ではない
• Permission denied なのに AVC に出ないときは dontaudit を疑い、semodule -DB で確認して semodule -B で戻す
• chcon は一時的、semanage fcontext + restorecon が永続。登録と反映は 2 段構えで、片方だけでは効かない
• Control Plane に同じ設定を入れると etcd と scheduler が壊れる。 /var/lib/etcd が var_lib_t、/etc/kubernetes/*.conf が kubernetes_file_t であるため。どこまでやるかを根拠を持って決めるのがハードニング
• AppArmor は RHEL 系では動かない。非対応ノードでは phase: Failed / STATUS 列 AppArmor で拒否される。判定は cat /sys/kernel/security/lsm の 1 行で足りる
• これらの部品が、第8回 PSS Restricted の要件を構成する

理解度チェック（○×形式・全 9 問）#

次の各文が正しいか（○）誤りか（×）を判断してください。下の「解答と解説」を開くと答え合わせができます。

1. fanclub-backend は 8080 番で待ち受けるので、capabilities.drop: [ALL] に加えて NET_BIND_SERVICE の add が必要である
2. privileged: true のコンテナにも seccomp プロファイルは必ず適用される
3. ホストの getenforce が Enforcing であれば、コンテナは必ず SELinux で拘束されている
4. containerd の enable_selinux を true にして再起動すると、稼働中のコンテナも即座に container_t になる
5. Kubernetes の Pod spec では、ボリュームに :z / :Z を付けてラベルを付け替える
6. hostPath でマウントしたディレクトリは kubelet が自動でリラベルしてくれる
7. Permission denied が出ているのに ausearch -m AVC に何も出なければ、原因は SELinux ではないと断定してよい
8. AlmaLinux（RHEL 系）で appArmorProfile を指定した Pod は Pending のまま留まる
9. seccomp の Localhost プロファイルは /var/lib/kubelet/seccomp/ 配下に置く

次回予告#

第7回「ホスト OS の攻撃面最小化と権限管理」では、D3 の後半としてカーネル層から一段上がり、ノード OS 自体の攻撃面を削ります。稼働サービス・パッケージ・開放ポートを棚卸しして不要なものを止め、OS ユーザと sudo・SSH の最小権限を設計し、firewalld でノードからの外部通信を絞ります。

本回は「動いているものをどう拘束するか」でしたが、次回は「そもそも動かさない」という方向の防御です。あわせて「閉じすぎてクラスタを壊さない境界」も扱います。本回で enable_selinux を Workload Node に限定したのと同じく、どこで止めるかの判断が主題になります。

→ 詳しくは 第7回 ホスト OS の攻撃面最小化と権限管理

リンク