PSS RestrictedとAdmission【CKS第8回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第8回です。第7回まではノードを 1 台ずつ手で締めてきました。本回から向きが変わります。クラスタの入口で、違反した Pod をそもそも作らせない側に立ちます。

本回の主題は 1 文で書けます。namespace にラベルを 1 行貼るだけで、Pod のセキュリティ水準を強制できる。 ただし、その 1 行がいつ・誰を・どう壊すかを知らずに貼ると、壊れたことにすら気づけません。

本回から D4（Minimize Microservice Vulnerabilities）に入ります。扱うのは PSS / PSA（組込・ラベルだけ）、ValidatingAdmissionPolicy（組込・CEL）、OPA Gatekeeper（外部・Rego）の 3 つです。実機作業は k8s-ops からの kubectl が中心で、やってみよう④ のみ Control Plane 3 台に触ります。

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

本回から CKS ドメイン D4: Minimize Microservice Vulnerabilities（配点 20%） です。D4 は 4 つのコンピテンシーからなり、本回が担当するのは 1 つ目です。残る 3 つは第9回・第10回・第11回で埋めます。

既習範囲 / 本回で上書きする観点#

第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）

第4部 ワークロード防御（D4）
  ★ 第8回: Pod Security Standards + Admission（D4）  ← 今ここ
    第9回: Secret 管理（etcd 暗号化 / SealedSecrets / ExternalSecrets）（D4）

本回の起点#

起点は第7回の完了状態です。第2巻から引き継いだ 9 VM 構成（Control Plane Node 3 台 + Workload Node 2 台 + 作業端末・レジストリ・LB・プロキシ）が稼働している前提で進めます。ラボの Kubernetes が v1.36.3 なのは、第5回のパッチアップグレード演習を通した後の状態だからです。

演習の進め方#

この回のゴール#

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

• PSS の 3 プロファイルと PSA の 3 モードを説明し、namespace ラベルで設定できる
• 既存 Pod の違反を壊さずに数える手順（enforce ラベル + --dry-run=server）を実行できる
• enforce を貼った後にどこが壊れ、どのコマンドで原因が見えるか（describe rs の FailedCreate）を説明できる
• AdmissionConfiguration でクラスタ全体の既定を決め、HA の 3 台すべてに配れる
• fanclub の 5 ワークロードを Restricted へ上げられる（正本が Git か Helm chart かを見分けたうえで）
• PSS で表現できない制約を VAP（CEL）と Gatekeeper（Rego）で書き分け、fail-open / fail-closed の差で選択できる

Pod Security Standards の 3 プロファイルと PSA の 3 モード#

Pod Security Standards（PSS） は、Pod のセキュリティ水準を 3 段階で定義した公式標準です。かつての PodSecurityPolicy（PSP）は v1.25 で削除済みで、現在は PSS（標準の定義）と、それを強制する Pod Security Admission（PSA）の 2 本立てになっています。

ここで Admission（アドミッション）という語を使いました。認証・認可を通った API リクエストが etcd に書かれる直前に、内容を検査して通す / 拒む / 書き換える段階のことです。PSA はその段階で動く Kubernetes 組込の Admission プラグインで、namespace のラベルを見て判定します。

PSA は namespace のラベルで適用します。ラベルは pod-security.kubernetes.io/<mode> と pod-security.kubernetes.io/<mode>-version の 2 種類です。

audit モードが書き込む先は API Server の監査ログです。何がどう記録されるかは第16回で Audit Policy とあわせて扱うので、本回では「記録される」ところまでにします。

• -version ラベルはプロファイル定義のバージョンを指定します。latest にすると Kubernetes をアップグレードした瞬間に判定が厳しくなることがあります。本番では v1.36 のようにマイナーで固定するのが安全です（本書ラボは学習のため latest を使います）
• 3 モードは併用できます。enforce=baseline + warn=restricted + audit=restricted のように、「止めるのは baseline まで、restricted 違反は知らせるだけ」という組み方が定石です

Restricted が要求するもの（第6回の primitive の束）#

Restricted は次を要求します。いずれも 第6回で個別に扱った部品です。

既存 Pod の違反を壊さずに数える — enforce + --dry-run=server だけが列挙する#

ラベルを貼る前に「いま何件違反しているか」を知りたい。壊さずに数える方法は 1 つしかありません。

ここで --dry-run=server を使います。API Server に「実際に書き込む直前まで」処理させて結果だけ返させるオプションで、Admission は通るので、拒否や警告はそのまま出ます。

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest --dry-run=server

実行結果：

Warning: existing pods in namespace "fanclub" violate the new PodSecurity enforce level "restricted:latest"
Warning: fanclub-backend-b4578bc-22gxg (and 2 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true
Warning: fanclub-db-0 (and 4 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/fanclub labeled (server dry run)

Pod 名のハッシュ部（fanclub-backend-b4578bc-22gxg）は Pod が作り直されるたびに変わります。手元の値が本書と一致しなくても問題ありません。

まとめられた Pod の数を足すと 3 + 5 = 8 で、kubectl -n fanclub get pod の 8 件と一致します。

出力の読み方を 3 点に分解します。

1. (and N other pods) —— 同じ違反の組み合わせを持つ Pod をまとめています。違反の「組み合わせ」ごとに 1 行にまとめられるので、行数は Pod 数と一致しません
2. backend の違反が 3 項目、他が 4 項目なのは、backend だけ Pod レベルに seccompProfile があるからです（第6回で入れました）。seccompProfile の 1 項目だけが差になっています
3. namespace/fanclub labeled (server dry run) —— 末尾のこの 1 行が「実際には書き込んでいない」証拠です

warn と audit の dry-run では 1 行も出ない#

同じことを warn で試すと、結果が変わります。

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

$ kubectl label ns fanclub pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/warn-version=latest --dry-run=server

実行結果：

namespace/fanclub labeled (server dry run)

警告は 1 行も出ません。同じ restricted を指定しているのに、enforce のときは 3 行出て、warn では 0 行です。

baseline で当てると距離が分かる#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=baseline pod-security.kubernetes.io/enforce-version=latest --dry-run=server

実行結果：

namespace/fanclub labeled (server dry run)

fanclub には hostPath / hostNetwork / hostPID / hostIPC が 1 つもありません。したがって Baseline には既に適合しており、Restricted までの距離だけが残っています。

fanclub の Pod が使っているボリュームの種別を数えると configMap / emptyDir / persistentVolumeClaim の 3 つだけです。この 3 つは Restricted が許すボリューム種別に含まれます。Baseline / Restricted が拒むのは hostPath のようにノードのファイルシステムへ直接触れる種別で、PVC は Longhorn 経由でも問題になりません。

warn の本当の使いどころ — Deployment を更新した瞬間に警告する#

warn が無意味なわけではありません。効くタイミングが違います。

ラベルが無い状態での実行結果：

deployment.apps/fanclub-frontend env updated

warn=restricted を貼った状態での実行結果：

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/fanclub-frontend env updated

どちらも env updated で成功しています。警告は更新を止めません。 止めないからこそ、enforce に上げる前の準備期間に貼っておく価値があります。

やってみよう①：fanclub の違反を壊さずに数え、warn を貼る#

対象は k8s-ops 上の kubectl だけです。Control Plane Node には触りません。

本文のコマンドは読みやすさのため kubectl と書いていますが、試験では alias k=kubectl が最初から設定されています（bash 補完も入っています）。本回は kubectl の比重が高いので、手元でも alias k=kubectl を設定しておくと写経が速くなります。

ステップ1：現状のラベルを確認する#

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

$ kubectl get ns fanclub -o jsonpath='{.metadata.labels}'

実行結果：

{"app.kubernetes.io/managed-by":"Helm","kubernetes.io/metadata.name":"fanclub"}

pod-security.kubernetes.io/ で始まるラベルは 1 つもありません。PSA が何も効いていない状態が出発点です。

ステップ2：baseline と restricted の 2 段階で dry-run する#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=baseline pod-security.kubernetes.io/enforce-version=latest --dry-run=server

実行結果：

namespace/fanclub labeled (server dry run)

警告は 0 行です。Baseline なら今すぐ貼っても 1 Pod も壊れません。

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest --dry-run=server

実行結果：

Warning: existing pods in namespace "fanclub" violate the new PodSecurity enforce level "restricted:latest"
Warning: fanclub-backend-b4578bc-22gxg (and 2 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true
Warning: fanclub-db-0 (and 4 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/fanclub labeled (server dry run)

まとめられた Pod 数を足すと 3 + 5 = 8 で、fanclub の Pod 総数と一致します。Pod 名のハッシュ部は環境ごとに変わります。

ステップ3：何が足りないかを 1 つずつ数える#

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

$ kubectl -n fanclub get pod -o custom-columns='NAME:.metadata.name,RUNASNONROOT:.spec.securityContext.runAsNonRoot,SECCOMP:.spec.securityContext.seccompProfile.type'

実行結果：

NAME                                RUNASNONROOT   SECCOMP
fanclub-backend-b4578bc-22gxg       <none>         RuntimeDefault
fanclub-backend-b4578bc-bdw5n       <none>         RuntimeDefault
fanclub-backend-b4578bc-v6fpl       <none>         RuntimeDefault
fanclub-db-0                        <none>         <none>
fanclub-frontend-76b8b6b9c5-8mz6l   <none>         <none>
fanclub-frontend-76b8b6b9c5-b4xmr   <none>         <none>
fanclub-logcollector-r5vjs          <none>         <none>
fanclub-logcollector-sh5tq          <none>         <none>

SECCOMP 列に値があるのは backend の 3 Pod だけです。第6回で Pod レベルに seccompProfile: RuntimeDefault を入れたのが、そのまま見えています。RUNASNONROOT 列が全部 <none> なのは、backend の runAsNonRoot が Pod レベルではなくコンテナレベルに書かれているからです。この列は Pod レベルだけを見ています。

ステップ4：warn と audit を貼る（enforce はまだ貼らない）#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/warn-version=latest pod-security.kubernetes.io/audit=restricted pod-security.kubernetes.io/audit-version=latest

実行結果：

namespace/fanclub labeled

ステップ5：warn が効くことを確かめる#

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

$ kubectl -n fanclub set env deploy/fanclub-frontend PSS_PROBE=1

実行結果：

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/fanclub-frontend env updated

警告は出ますが、更新自体は成功しています（env updated）。warn は止める仕組みではありません。

ステップ6：後片付け（環境変数を戻す）#

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

$ kubectl -n fanclub set env deploy/fanclub-frontend PSS_PROBE-

実行結果：

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/fanclub-frontend env updated

環境変数を消す操作にも同じ警告が出ます。 warn は「この Pod テンプレートは Restricted を満たさない」と言っているだけなので、変更の中身に関係なく、更新のたびに出ます。

enforce を貼った後、何がいつ壊れるか#

enforce=restricted を貼ると何が起きるか。4 つの時点に分けて整理します。

Pod 単体の拒否メッセージ（読み方の練習）#

やってみよう② ステップ4 で、次のコマンドを打つと拒否されます。

コマンド（この節では打ちません）：

$ kubectl -n fanclub run probe-frontend --image=k8s-registry:5000/fanclub-frontend:1.0.0

そのときの実行結果：

Error from server (Forbidden): pods "probe-frontend" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "probe-frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "probe-frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "probe-frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "probe-frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

rollout restart は成功を返すのに Pod が作られない#

ここが本回で最も診断しにくい状態です。

コマンド（この節では打ちません・やってみよう② ステップ5）：

$ kubectl -n fanclub rollout restart deploy/fanclub-frontend

そのときの実行結果：

deployment.apps/fanclub-frontend restarted

成功したように見えます。 ところが新しい Pod は 1 つも作られません。しかも kubectl get deploy は健全に見えます。

コマンド（やってみよう② ステップ5）：

$ kubectl -n fanclub get deploy fanclub-frontend

そのときの実行結果：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
fanclub-frontend   2/2     0            2           42h

本当の状態は ReplicaSet 側にあります。

コマンド（やってみよう② ステップ6）：

$ kubectl -n fanclub get rs -l app=fanclub-frontend

そのときの実行結果：

NAME                          DESIRED   CURRENT   READY   AGE
fanclub-frontend-5dc7d8dd78   0         0         0       2m8s
fanclub-frontend-658b5cd5b9   1         0         0       30s
fanclub-frontend-76b8b6b9c5   2         2         2       27h
fanclub-frontend-7d9b4667f    0         0         0       42h
fanclub-frontend-d846969dc    0         0         0       49s

ReplicaSet は Pod テンプレートが変わるたびに増えます。やってみよう① で set env を 2 回打っているので、手元でも同じくらいの本数が並びます。読むべきは AGE が最も新しい 1 行で、ここでは fanclub-frontend-658b5cd5b9（30s）です。DESIRED 1 なのに CURRENT 0、つまり「1 つ作りたいのに 0 個しか作れていない」状態です（ローリング更新なので最初は 1 つずつ増やそうとします）。2 行目の 76b8b6b9c5 が 2/2/2 で生き残っているので、サービスは止まりません。

コマンド（<新しい RS 名> は上の出力から取ります）：

$ kubectl -n fanclub describe rs <新しい RS 名>

実行結果（Events 節の抜粋）：

Events:
  Type     Reason        Age   From                   Message
  ----     ------        ----  ----                   -------
  Warning  FailedCreate  30s   replicaset-controller  Error creating: pods "fanclub-frontend-658b5cd5b9-8wdxk" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
  Warning  FailedCreate  30s   replicaset-controller  Error creating: pods "fanclub-frontend-658b5cd5b9-wbz79" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

ReplicaSet 名と Pod 名のハッシュ部、経過秒数は実行のたびに変わります。同じ内容の FailedCreate が何行も並ぶのは、ReplicaSet コントローラが作成を諦めずに再試行しているからです。

復旧は速いです。ラベルを外すと数十秒で新しい Pod が作られます（本書ラボの実測では UP-TO-DATE が戻るまで 25 秒）。ReplicaSet コントローラは失敗をバックオフしながら再試行し続けているので、拒否の原因が消えた瞬間に成功します。「壊れたら戻せる」ことを確かめておくと、本番でラベルを貼る手が軽くなります。

実際の復旧の様子（やってみよう② ステップ7〜8 で確認します）：

NAME                                READY   STATUS              RESTARTS      AGE
fanclub-frontend-658b5cd5b9-fhb66   0/1     ContainerCreating   0             1s
fanclub-frontend-658b5cd5b9-rs2zz   1/1     Running             0             2s
fanclub-frontend-76b8b6b9c5-8mz6l   1/1     Running             6 (14m ago)   11h
fanclub-frontend-76b8b6b9c5-b4xmr   0/1     Completed           6 (14m ago)   11h

やってみよう②：enforce を貼って空振りを体験し、外して戻す#

対象は k8s-ops 上の kubectl だけです。Control Plane Node には触りません。前提はやってみよう① を実施済みであること（warn / audit は貼ってあり、enforce は貼っていない状態）です。

ステップ1：貼る前の状態を記録する#

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

$ kubectl -n fanclub get pod

実行結果：

NAME                                READY   STATUS    RESTARTS      AGE
fanclub-backend-b4578bc-22gxg       2/2     Running   4 (16m ago)   11h
fanclub-backend-b4578bc-bdw5n       2/2     Running   4 (16m ago)   11h
fanclub-backend-b4578bc-v6fpl       2/2     Running   4 (16m ago)   11h
fanclub-db-0                        1/1     Running   0             10m
fanclub-frontend-76b8b6b9c5-8mz6l   1/1     Running   6 (12m ago)   11h
fanclub-frontend-76b8b6b9c5-b4xmr   1/1     Running   6 (12m ago)   11h
fanclub-logcollector-r5vjs          1/1     Running   2 (16m ago)   11h
fanclub-logcollector-sh5tq          1/1     Running   4 (16m ago)   27h

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

$ kubectl -n fanclub get deploy

実行結果：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
fanclub-backend    3/3     3            3           42h
fanclub-frontend   2/2     2            2           42h

8 Pod・UP-TO-DATE は 2 つとも満たされている——この 2 つの数字を覚えておいてください。ステップ5 で比べます。

ステップ2：enforce=restricted を貼る#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest

実行結果：

Warning: existing pods in namespace "fanclub" violate the new PodSecurity enforce level "restricted:latest"
Warning: fanclub-backend-b4578bc-22gxg (and 2 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true
Warning: fanclub-db-0 (and 4 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/fanclub labeled

dry-run のときと同じ警告が返り、末尾だけが (server dry run) の無い namespace/fanclub labeled に変わっています。 今度は本当に書き込まれました。

ステップ3：既存 Pod が死んでいないことを確かめる#

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

$ kubectl -n fanclub get pod

実行結果：

NAME                                READY   STATUS    RESTARTS      AGE
fanclub-backend-b4578bc-22gxg       2/2     Running   4 (16m ago)   11h
fanclub-backend-b4578bc-bdw5n       2/2     Running   4 (16m ago)   11h
fanclub-backend-b4578bc-v6fpl       2/2     Running   4 (16m ago)   11h
fanclub-db-0                        1/1     Running   0             10m
fanclub-frontend-76b8b6b9c5-8mz6l   1/1     Running   6 (12m ago)   11h
fanclub-frontend-76b8b6b9c5-b4xmr   1/1     Running   6 (12m ago)   11h
fanclub-logcollector-r5vjs          1/1     Running   2 (16m ago)   11h
fanclub-logcollector-sh5tq          1/1     Running   4 (16m ago)   27h

ステップ1 と 1 行も変わりません。 RESTARTS も増えていません。

ステップ4：Pod を単体で作ろうとして拒否される#

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

$ kubectl -n fanclub run probe-frontend --image=k8s-registry:5000/fanclub-frontend:1.0.0

実行結果：

Error from server (Forbidden): pods "probe-frontend" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "probe-frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "probe-frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "probe-frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "probe-frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

ステップ5：rollout restart が空振りすることを確かめる#

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

$ kubectl -n fanclub rollout restart deploy/fanclub-frontend

実行結果：

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/fanclub-frontend restarted

warn ラベルのおかげで警告は出ますが、最後の行は restarted——成功です。

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

$ kubectl -n fanclub get deploy fanclub-frontend

実行結果（30 秒ほど待ってから）：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
fanclub-frontend   2/2     0            2           42h

kubectl get deploy の 4 つの列を、ここで 1 つずつ読んでください。

監視が READY しか見ていないと、この状態は永久に検知されません。

ステップ6：describe rs で原因を見る#

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

$ kubectl -n fanclub get rs -l app=fanclub-frontend

実行結果：

NAME                          DESIRED   CURRENT   READY   AGE
fanclub-frontend-5dc7d8dd78   0         0         0       2m8s
fanclub-frontend-658b5cd5b9   1         0         0       30s
fanclub-frontend-76b8b6b9c5   2         2         2       27h
fanclub-frontend-7d9b4667f    0         0         0       42h
fanclub-frontend-d846969dc    0         0         0       49s

AGE が最も新しい行（ここでは fanclub-frontend-658b5cd5b9）が、rollout restart で作られた ReplicaSet です。DESIRED 1 に対して CURRENT 0 ——作りたいのに作れていません。

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

$ kubectl -n fanclub describe rs <新しい RS 名>

実行結果（Events 節の抜粋）：

Events:
  Type     Reason        Age   From                   Message
  ----     ------        ----  ----                   -------
  Warning  FailedCreate  30s   replicaset-controller  Error creating: pods "fanclub-frontend-658b5cd5b9-8wdxk" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

ステップ7：ラベルを外す#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce- pod-security.kubernetes.io/enforce-version-

実行結果：

namespace/fanclub unlabeled

ラベル名の末尾に付けたハイフンが「そのラベルを削除する」という意味です。= を書かずにハイフンで終える、という書き方は kubectl label と kubectl annotate に共通です。

ステップ8：回復を確認する#

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

$ kubectl -n fanclub get pod -w

実行結果（抜粋）：

NAME                                READY   STATUS              RESTARTS      AGE
fanclub-frontend-658b5cd5b9-fhb66   0/1     ContainerCreating   0             1s
fanclub-frontend-658b5cd5b9-rs2zz   1/1     Running             0             2s
fanclub-frontend-76b8b6b9c5-8mz6l   1/1     Running             6 (14m ago)   11h
fanclub-frontend-76b8b6b9c5-b4xmr   0/1     Completed           6 (14m ago)   11h

本書ラボでは、ラベルを外してから UP-TO-DATE が 2 に戻るまで 25 秒でした。ReplicaSet コントローラが再試行を続けていたので、拒否の原因が消えた瞬間に成功します。

-w は変化を監視し続けるオプションなので、新しい Pod が Running になったら Ctrl+C で抜けてください。

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

$ kubectl -n fanclub get deploy fanclub-frontend

実行結果：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
fanclub-frontend   2/2     2            2           42h

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

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

実行結果：

200

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

ステップ9：後片付けの確認#

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

$ kubectl get ns fanclub -o jsonpath='{.metadata.labels}'

実行結果：

{"app.kubernetes.io/managed-by":"Helm","kubernetes.io/metadata.name":"fanclub","pod-security.kubernetes.io/audit":"restricted","pod-security.kubernetes.io/audit-version":"latest","pod-security.kubernetes.io/warn":"restricted","pod-security.kubernetes.io/warn-version":"latest"}

enforce 系の 2 つが消え、やってみよう① で貼った warn / audit の 4 つだけが残っています。 これが次のやってみようの出発点です。

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

$ kubectl -n fanclub get pod probe-frontend

実行結果：

Error from server (NotFound): pods "probe-frontend" not found

拒否された Pod は存在しません（作成そのものが止められたため）。削除は不要です。

やってみよう③：クラスタ全 namespace を PSS で棚卸しする#

「どの namespace を Restricted にできるか」は、実測しないと決められません。1 Pod も壊さずに、クラスタ全体の距離を測ります。

ステップ1：全 namespace に baseline を dry-run で当てる#

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

$ for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do echo "=== $ns ==="; kubectl label ns $ns pod-security.kubernetes.io/enforce=baseline pod-security.kubernetes.io/enforce-version=latest --dry-run=server --overwrite 2>&1 | grep -c '^Warning:'; done

実行結果：

=== argocd ===
0
=== cert-manager ===
0
=== default ===
0
=== fanclub ===
0
=== kube-node-lease ===
0
=== kube-public ===
0
=== kube-system ===
3
=== local-path-storage ===
0
=== longhorn-system ===
4
=== metallb-system ===
2
=== monitoring ===
3
=== traefik ===
0
=== velero ===
2

ステップ2：同じことを restricted で当てる#

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

$ for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do echo "=== $ns ==="; kubectl label ns $ns pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest --dry-run=server --overwrite 2>&1 | grep -c '^Warning:'; done

実行結果：

=== argocd ===
0
=== cert-manager ===
0
=== default ===
0
=== fanclub ===
3
=== kube-node-lease ===
0
=== kube-public ===
0
=== kube-system ===
6
=== local-path-storage ===
2
=== longhorn-system ===
5
=== metallb-system ===
3
=== monitoring ===
5
=== traefik ===
0
=== velero ===
3

ステップ3：結果を表にまとめる#

この表は、本回の後半でもう 1 行増えます。 やってみよう⑥ で OPA Gatekeeper を入れると gatekeeper-system が生まれますが、それは最初から Restricted 適合の状態で入ってきます（後の節で確認します）。

ステップ4：すでに chart がラベルを貼っている namespace を確認する#

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

$ kubectl get ns -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce,VERSION:.metadata.labels.pod-security\.kubernetes\.io/enforce-version'

実行結果：

NAME                 ENFORCE      VERSION
argocd               <none>       <none>
cert-manager         <none>       <none>
default              <none>       <none>
fanclub              <none>       <none>
kube-node-lease      <none>       <none>
kube-public          <none>       <none>
kube-system          <none>       <none>
local-path-storage   <none>       <none>
longhorn-system      <none>       <none>
metallb-system       <none>       <none>
monitoring           <none>       <none>
traefik              <none>       <none>
velero               privileged   latest

13 の namespace のうち、enforce ラベルを持っているのは velero だけです。これは読者が貼ったものではなく、Velero の Helm chart が自分で貼ったものです。第2巻第14回で Velero を入れた時点から付いていました。

namespace ラベルは貼り忘れる — AdmissionConfiguration でクラスタ既定を決める#

PSA の namespace ラベル方式には、はっきりした穴があります。

これを塞ぐのが AdmissionConfiguration による既定値です。API Server の起動時に読ませる設定ファイルで、Admission プラグインごとの既定値を書けます。PSA の場合は「ラベルが無い namespace に何を適用するか」を決めます。

現状の確認#

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

$ sudo grep -n "enable-admission-plugins\|admission-control-config-file" /etc/kubernetes/manifests/kube-apiserver.yaml

実行結果：

19:    - --enable-admission-plugins=NodeRestriction

--admission-control-config-file は 1 行もヒットしません。 つまり クラスタ全体の既定は「ラベルが無ければ何でも通る」という状態です。

書くファイル（全量）#

/etc/kubernetes/admission/admission-config.yaml の内容です。

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: "baseline"
        enforce-version: "latest"
        warn: "restricted"
        warn-version: "latest"
        audit: "restricted"
        audit-version: "latest"
      exemptions:
        usernames: []
        runtimeClasses: []
        namespaces: ["kube-system"]

設計の要点は 3 つです。

1. defaults は「ラベルが無い namespace に適用される値」です。ラベルがあればラベルが勝ちます。既定を厳しくしても、明示ラベルで個別に緩められます
2. enforce: baseline + warn/audit: restricted の組み合わせが実務の落としどころです。止めるのは baseline まで、restricted 違反は知らせるだけという設計になります
3. exemptions は 3 種類（usernames / runtimeClasses / namespaces）です。kube-system は必ず外します（static Pod が privileged なので、外さないと Control Plane の再作成が止まります）

HA では 3 台すべてに配る#

cp-01 だけに設定を入れて実測した結果です。

コマンド（cp-01 を経由する場合・この節では打ちません）：

$ kubectl --server=https://192.168.1.125:6443 --insecure-skip-tls-verify -n default apply -f hostpath-pod.yaml --dry-run=server

そのときの実行結果：

Error from server (Forbidden): pods "hostpath-probe" is forbidden: violates PodSecurity "baseline:latest": hostPath volumes (volume "h")

コマンド（cp-02 を経由する場合・この節では打ちません）：

$ kubectl --server=https://192.168.1.126:6443 --insecure-skip-tls-verify -n default apply -f hostpath-pod.yaml --dry-run=server

そのときの実行結果：

pod/hostpath-probe created (server dry run)

--dry-run=server を付けているので、どちらも Pod を作っていません。 それでも Admission の判定は本番と同じように走るので、「拒否されなかった」ことの証拠になります。 何も作らずにポリシーの効き方だけを比べられる、この節にちょうどよい確かめ方です。

適用前に必ず済ませておくこと#

enforce: baseline を既定にすると、前節の棚卸しで baseline を満たせなかった namespace（longhorn-system / metallb-system / monitoring / velero / local-path-storage）が baseline 判定になります。

exemptions.namespaces に並べるより、明示ラベルのほうが後から読めます（本書の推奨）。exemptions は API Server の設定ファイルの中にあるので、クラスタを触る人が kubectl からは見えません。 一方、kubectl get ns --show-labels は誰でも打てます。「なぜこの namespace は privileged なのか」を後任者が追える形にしておいてください。exemptions に書くのは kube-system のように「ラベルを貼る前に API Server が起動する必要があるもの」に限ります。

やってみよう④：3 台の Control Plane にクラスタ全体デフォルトを配る#

対象は k8s-cp-01 / k8s-cp-02 / k8s-cp-03 です。本回で唯一、Control Plane に変更を加える演習になります。

ステップ1：特権が必要な namespace へ明示ラベルを先に貼る#

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

$ kubectl label ns longhorn-system metallb-system monitoring local-path-storage pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/enforce-version=latest --overwrite

実行結果：

namespace/longhorn-system labeled
namespace/metallb-system labeled
namespace/monitoring labeled
namespace/local-path-storage labeled

velero は chart が既に privileged を貼っているので対象外にしています（やってみよう③ ステップ4 で確認しました）。kube-system は次のステップの exemptions で除外するので、ここでは貼りません。

ステップ2：3 台の Control Plane すべてに設定ファイルを置く#

実行コマンド（k8s-cp-01 / cp-02 / cp-03 それぞれの上・root）：

# mkdir -p /etc/kubernetes/admission

実行結果：

（出力はありません）

mkdir -p は、すでにディレクトリがあっても何も言わずに成功します。3 台とも同じです。

同じく 3 台それぞれで、設定ファイルを heredoc で作成します。

実行コマンド（k8s-cp-01 / cp-02 / cp-03 それぞれの上・root）：

# cat > /etc/kubernetes/admission/admission-config.yaml <<'EOF'
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: "baseline"
        enforce-version: "latest"
        warn: "restricted"
        warn-version: "latest"
        audit: "restricted"
        audit-version: "latest"
      exemptions:
        usernames: []
        runtimeClasses: []
        namespaces: ["kube-system"]
EOF

実行コマンド（3 台それぞれの上・root）：

# ls -l /etc/kubernetes/admission/admission-config.yaml

実行結果（3 台とも同じ）：

-rw-r--r--. 1 root root 512  7月 27 21:27 /etc/kubernetes/admission/admission-config.yaml

実行コマンド（3 台それぞれの上・root）：

# cat /etc/kubernetes/admission/admission-config.yaml

3 台の内容が同じであることは md5sum で機械的に確かめられます。

実行コマンド（3 台それぞれの上・root）：

# md5sum /etc/kubernetes/admission/admission-config.yaml

実行結果（3 台とも同じハッシュになること）：

b16f534d91ec742f9988576b67a0ec57  /etc/kubernetes/admission/admission-config.yaml

ハッシュが 1 台でも違ったら、その 1 台だけポリシーが変わります。 見た目で確認せず、必ず機械で突き合わせてください。

ステップ3：kubeadm-config ConfigMap に登録する（正本を先に更新する）#

編集方式は第5回で確立した作法をそのまま使います。バックアップを取ってから kubectl edit で apiServer: ブロックを全量置き換える、という手順です。kubectl patch は使いません（配列の一部だけを差し替えると既存の 5 フラグを壊しやすいためです）。

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

$ kubectl -n kube-system get cm kubeadm-config -o jsonpath='{.data.ClusterConfiguration}'

実行結果：

apiServer:
  extraArgs:
  - name: authentication-config
    value: /etc/kubernetes/auth/anonymous.yaml
  - name: kubelet-certificate-authority
    value: /etc/kubernetes/pki/ca.crt
  - name: profiling
    value: "false"
  - name: service-account-extend-token-expiration
    value: "false"
  - name: service-account-max-token-expiration
    value: 24h
  extraVolumes:
  - hostPath: /etc/kubernetes/auth
    mountPath: /etc/kubernetes/auth
    name: auth-config
    pathType: DirectoryOrCreate
    readOnly: true
apiVersion: kubeadm.k8s.io/v1beta4
caCertificateValidityPeriod: 87600h0m0s
certificateValidityPeriod: 8760h0m0s
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: k8s-lb:6443
controllerManager: {}
dns: {}
encryptionAlgorithm: RSA-2048
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: registry.k8s.io
kind: ClusterConfiguration
kubernetesVersion: v1.36.3
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
proxy: {}
scheduler: {}

apiServer.extraArgs に 第5回で足した 5 フラグ、extraVolumes に auth-config の 1 つがあります。ここへ 1 フラグと 1 ボリュームを足すのが本ステップです。

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

$ kubectl get cm kubeadm-config -n kube-system -o yaml > ~/kubeadm-config.bak-08.yaml

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

$ kubectl edit cm kubeadm-config -n kube-system

apiServer: ブロックを、次の内容で丸ごと置き換えます。第5回の 5 フラグ + 1 extraVolume に、本回の 1 フラグ + 1 extraVolume を足したマージ後の全量です。

apiServer:
  extraArgs:
  - name: authentication-config
    value: /etc/kubernetes/auth/anonymous.yaml
  - name: kubelet-certificate-authority
    value: /etc/kubernetes/pki/ca.crt
  - name: profiling
    value: "false"
  - name: service-account-extend-token-expiration
    value: "false"
  - name: service-account-max-token-expiration
    value: 24h
  - name: admission-control-config-file
    value: /etc/kubernetes/admission/admission-config.yaml
  extraVolumes:
  - name: auth-config
    hostPath: /etc/kubernetes/auth
    mountPath: /etc/kubernetes/auth
    readOnly: true
    pathType: DirectoryOrCreate
  - name: admission-config
    hostPath: /etc/kubernetes/admission
    mountPath: /etc/kubernetes/admission
    readOnly: true
    pathType: DirectoryOrCreate

書式の注意点は第5回で説明したとおりです。extraArgs は kubeadm.k8s.io/v1beta4 から name / value のリスト形式で、フラグ名の先頭の -- は書きません。

保存すると configmap/kubeadm-config replaced と表示されます。もう一度読み出すと、追記した 1 フラグと 1 ボリュームが入っていることを確認できます。

実行結果（apiServer: ブロックの抜粋）：

apiServer:
  extraArgs:
  - name: authentication-config
    value: /etc/kubernetes/auth/anonymous.yaml
  - name: kubelet-certificate-authority
    value: /etc/kubernetes/pki/ca.crt
  - name: profiling
    value: 'false'
  - name: service-account-extend-token-expiration
    value: 'false'
  - name: service-account-max-token-expiration
    value: 24h
  - name: admission-control-config-file
    value: /etc/kubernetes/admission/admission-config.yaml
  extraVolumes:
  - hostPath: /etc/kubernetes/auth
    mountPath: /etc/kubernetes/auth
    name: auth-config
    pathType: DirectoryOrCreate
    readOnly: true
  - hostPath: /etc/kubernetes/admission
    mountPath: /etc/kubernetes/admission
    name: admission-config
    pathType: DirectoryOrCreate
    readOnly: true

ここで ConfigMap を直しても、動いている API Server は変わりません。 ConfigMap は「次に kubeadm がマニフェストを作り直すときの材料」です。いま効かせるには、次のステップで 3 台のマニフェストを直接書き換えます。

ステップ4：3 台の static Pod マニフェストへ反映する#

実行コマンド（各 Control Plane Node 上・developer・編集する前に必ず）：

$ sudo cp -p /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak-08

実行結果（成功すると何も表示されません）：

（出力はありません）

実行コマンド（各 Control Plane Node 上・developer）：

$ sudo ls -l /root/kube-apiserver.yaml.bak-08

実行結果（cp-01 の例）：

-rw-------. 1 root root 4788  7月 26 22:03 /root/kube-apiserver.yaml.bak-08

置けたことを確かめてから次へ進みます。cp -p の -p は 更新時刻とパーミッションを保つオプションです。

各 Control Plane Node で /etc/kubernetes/manifests/kube-apiserver.yaml に次の 3 箇所を足します。

command に追加する 1 行：

    - --admission-control-config-file=/etc/kubernetes/admission/admission-config.yaml

volumeMounts に追加する 1 項目：

    - mountPath: /etc/kubernetes/admission
      name: admission-config
      readOnly: true

volumes に追加する 1 項目：

  - hostPath:
      path: /etc/kubernetes/admission
      type: DirectoryOrCreate
    name: admission-config

実行コマンド（各 Control Plane Node 上・root・1 台ずつ）：

# crictl ps --name kube-apiserver

実行結果（cp-01 の例）：

CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD                        NAMESPACE
646eb586cb754       3400718b4dd57       2 seconds ago       Running             kube-apiserver      0                   d6db5ead2f457       kube-apiserver-k8s-cp-01   kube-system

CREATED が数秒前になっていれば、作り直された新しいコンテナです。ATTEMPT が 0 のままなのは、1 回で起動できた証拠です。ここが増えていく場合は起動に失敗して再試行しています。

実行コマンド（各 Control Plane Node 上・root・1 台ずつ）：

# curl -sk https://127.0.0.1:6443/livez

実行結果（3 台とも）：

ok

本書ラボの実測では、マニフェストを保存してから /livez が ok を返すまで 42〜45 秒でした（3 台の実測値）。

再起動まで 30 秒程度かかります。crictl ps に出てこない間は待ってください。 /etc/kubernetes/admission/ は 3 台すべてに作られている必要があります（hostPath の DirectoryOrCreate でディレクトリは作られますが、中の YAML は作られません）。

ステップ5：3 台それぞれに直接当てて、同じ結果が返ることを確かめる#

ここで --overrides を使います。kubectl run が作る Pod の spec に JSON で書いた内容を上書き・追加するオプションで、マニフェストファイルを作らずに 1 行で「hostPath を持つ Pod」を作れるので、ポリシーの動作確認に向いています。

実行コマンド（k8s-ops 上・developer・<CP の IP> は 192.168.1.125 / 192.168.1.126 / 192.168.1.127）：

$ kubectl --server=https://<CP の IP>:6443 --insecure-skip-tls-verify -n default run hostpath-probe --image=busybox:1.37 --overrides='{"spec":{"volumes":[{"name":"h","hostPath":{"path":"/etc"}}]}}' --command -- sleep 3600

実行結果（設定済みの Control Plane を経由した場合）：

Error from server (Forbidden): pods "hostpath-probe" is forbidden: violates PodSecurity "baseline:latest": hostPath volumes (volume "h")

3 台すべてで同じ拒否メッセージが返れば合格です。本書ラボでは 192.168.1.125 / 192.168.1.126 / 192.168.1.127 の 3 台とも、上と 1 文字も違わない出力になりました。

--server で IP を直接指定しているので --insecure-skip-tls-verify を併用します（証明書は k8s-lb 向けに発行されているため、IP 直指定では名前が一致しません）。

ステップ6：ラベルの無い namespace で warn の既定も効くことを確かめる#

default namespace には PSA ラベルが 1 つもありません。ラベルが無いので既定値（enforce: baseline / warn: restricted）が適用されます。

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

$ kubectl -n default run warn-probe --image=busybox:1.37 --command -- sleep 3600

実行結果：

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "warn-probe" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "warn-probe" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "warn-probe" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "warn-probe" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/warn-probe created

Restricted 違反の警告が出たうえで、Pod は作られています。 既定の enforce は baseline なので、hostPath を使っていないこの Pod は止められません。止めるのは baseline まで、restricted 違反は知らせるだけ——設計どおりの挙動です。

実行コマンド（確認できたら削除します）：

$ kubectl -n default delete pod warn-probe

実行結果：

pod "warn-probe" deleted from default namespace

ステップ7：kube-system の除外が効いていることを確かめる#

kube-system は exemptions.namespaces に書いたので、既定の baseline が適用されません。ここでは 実際には作らず --dry-run=server で確かめます（kube-system に不要な Pod を残さないため）。

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

$ kubectl -n kube-system run hostpath-probe-ks --image=busybox:1.37 --dry-run=server --overrides='{"spec":{"volumes":[{"name":"h","hostPath":{"path":"/etc"}}]}}' --command -- sleep 3600

実行結果：

pod/hostpath-probe-ks created (server dry run)

同じ hostPath Pod が、default では拒否され kube-system では通りました。 exemptions が効いている証拠です。Control Plane の static Pod は privileged で hostPath を使うので、ここを外さないとクラスタが自分を作り直せなくなります。

ステップ8：後片付け（必ず実施する）#

1. 3 台の /etc/kubernetes/manifests/kube-apiserver.yaml から追加した 3 箇所を削除し、API Server の復帰を 1 台ずつ確認する
2. kubeadm-config ConfigMap から追加した 2 項目（admission-control-config-file と admission-config の extraVolume）を削除する
3. hostpath-probe を削除する
4. ステップ1 で貼った privileged ラベルは残します（次回以降の環境として妥当なため）

後片付け後の確認（k8s-ops 上・developer）：

$ kubectl get nodes

実行結果：

NAME        STATUS   ROLES           AGE    VERSION
k8s-cp-01   Ready    control-plane   2d1h   v1.36.3
k8s-cp-02   Ready    control-plane   47h    v1.36.3
k8s-cp-03   Ready    control-plane   47h    v1.36.3
k8s-wl-01   Ready    <none>          47h    v1.36.3
k8s-wl-02   Ready    <none>          47h    v1.36.3

本書ラボでは 5 ノード Ready・98 Pod で異常 0・Longhorn 4 ボリューム attached healthy・https://fanclub.local/ が 200・ArgoCD Synced / Healthy に戻りました。マニフェストを書き戻してから /livez が ok を返すまでは 1 台あたり数十秒です。1 台ずつ戻し、ok を確認してから次の 1 台へ進んでください。

誰が Pod spec の正本を持っているか — Helm と ArgoCD の二重管理#

fanclub namespace の 5 つのワークロードは、2 つの経路で管理されています。fanclub を Restricted 化する前に、どこを直せば反映されるのかを確定させます。

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

$ kubectl -n fanclub get deploy,sts,ds,cronjob -o custom-columns='KIND:.kind,NAME:.metadata.name,HELM:.metadata.annotations.meta\.helm\.sh/release-name,ARGOCD:.metadata.annotations.argocd\.argoproj\.io/tracking-id'

実行結果：

KIND          NAME                   HELM      ARGOCD
Deployment    fanclub-backend        fanclub   fanclub-api-prod:apps/Deployment:fanclub/fanclub-backend
Deployment    fanclub-frontend       fanclub   fanclub-api-prod:apps/Deployment:fanclub/fanclub-frontend
StatefulSet   fanclub-db             fanclub   <none>
DaemonSet     fanclub-logcollector   fanclub   <none>
CronJob       fanclub-report         fanclub   <none>

backend と frontend だけが 2 つの annotation を持っています。 Helm が作り、ArgoCD が後から採用した（adopt した）——第2巻第14回で GitOps 化したときの経緯がそのまま残っています。

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

$ kubectl -n argocd get application fanclub-api-prod -o jsonpath='{.spec.source.repoURL}{"\n"}{.spec.source.path}{"\n"}{.spec.syncPolicy}'

実行結果：

{"path":"overlays/prod","repoURL":"http://k8s-registry:3000/developer/gitops-fanclub.git","targetRevision":"main"}
{"automated":{"prune":true,"selfHeal":true}}

selfHeal: true なので、kubectl edit で backend / frontend を直しても数十秒で Git の内容に戻されます。直す先は Git です。

Git の base/ には 6 ファイルしかありません（backend-deployment / frontend-deployment / configmap / services / resourcequota / kustomization）。db / logcollector / CronJob は Git に無いので、Helm chart 側を直して helm upgrade します。同じ namespace の中で、リソースごとに手順が変わります。

fanclub を Restricted へ上げる実測レシピ#

「Restricted にする」を、5 つのワークロードそれぞれの具体で示します。実測でしか分からない落とし穴が 3 つ（/var/run・fsGroup・initContainer）含まれます。

現状の securityContext は次のとおりです。第6回が触ったのは backend の Deployment だけで、他の 4 つは空です。

ここで書く securityContext は、第12回で扱う静的解析（Kubesec / KubeLinter）が kubectl apply する前に検査する対象でもあります。本回は「弾かれてから直す」、第12回は「apply する前に気づく」——同じフィールドを別の角度から見ることになります。

frontend（nginx）— /var/run の emptyDir が要る。NET_BIND_SERVICE は要らない#

fanclub-frontend は nginx を uid 0 で動かしており、nginx.conf に user nginx; / listen 80 が書かれています。Restricted 準拠にするために足すものは次のとおりです（実測で Running・uid 101・:80 応答を確認済み）。

      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: frontend
          securityContext:
            runAsNonRoot: true
            runAsUser: 101
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: nginx-cache
              mountPath: /var/cache/nginx
            - name: nginx-run
              mountPath: /var/run
      volumes:
        - name: nginx-cache
          emptyDir: {}
        - name: nginx-run
          emptyDir: {}

マージ後の ~/gitops/gitops-fanclub/base/frontend-deployment.yaml の全量：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fanclub-frontend
  labels:
    app: fanclub-frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fanclub-frontend
  template:
    metadata:
      labels:
        app: fanclub-frontend
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: frontend
        image: k8s-registry:5000/fanclub-frontend:1.0.0
        ports:
        - containerPort: 80
        securityContext:
          runAsNonRoot: true
          runAsUser: 101
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        resources:
          requests:
            memory: "32Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"
        volumeMounts:
        - name: config
          mountPath: /usr/share/nginx/html/config.js
          subPath: config.js
        - name: nginx-cache
          mountPath: /var/cache/nginx
        - name: nginx-run
          mountPath: /var/run
      volumes:
      - name: config
        configMap:
          name: fanclub-frontend-config
      - name: nginx-cache
        emptyDir: {}
      - name: nginx-run
        emptyDir: {}

replicas: 1 は base の値で、prod overlay が 2 に patch します（第2巻第14回で作った構成）。ここを 2 に書き換える必要はありません。

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

$ kubectl -n fanclub exec deploy/fanclub-frontend -- cat /proc/sys/net/ipv4/ip_unprivileged_port_start

実行結果：

0

実行ユーザも同じ形で確認できますが、いまここで打つと uid=0(root) が返ります（frontend はまだ直していません）。やってみよう⑤ を終えたあとに打つと、次のように変わります。

コマンド（やってみよう⑤ ステップ6 で打ちます）：

$ kubectl -n fanclub exec deploy/fanclub-frontend -- id

そのときの実行結果：

uid=101(nginx) gid=101(nginx) groups=101(nginx)

起動ログの警告は無害です。[warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2 が出ますが、user nginx; の行が無視されるだけです。すでに uid 101 で動いているので、変更する相手がいません。

db（PostgreSQL 18）— fsGroup: 999 が無いと initdb が失敗する#

fanclub-db は StatefulSet で、PGDATA=/var/lib/postgresql/data/pgdata・Longhorn の PVC をマウントしています。

Restricted 準拠の securityContext（Pod レベル）：

      securityContext:
        runAsNonRoot: true
        runAsUser: 999
        runAsGroup: 999
        fsGroup: 999
        seccompProfile:
          type: RuntimeDefault

コンテナレベル：

          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

マージ後の ~/fanclub-chart/templates/db-statefulset.yaml の全量：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: fanclub-db
  namespace: {{ .Values.namespace }}
spec:
  serviceName: fanclub-db
  replicas: 1
  selector:
    matchLabels:
      app: fanclub-db
  template:
    metadata:
      labels:
        app: fanclub-db
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 999
        runAsGroup: 999
        fsGroup: 999
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: postgres
        image: {{ .Values.db.image.repository }}:{{ .Values.db.image.tag }}
        ports:
        - containerPort: 5432
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        env:
        - name: POSTGRES_DB
          value: fanclubdb
        - name: POSTGRES_USER
          value: appuser
        - name: POSTGRES_PASSWORD
          value: apppassword
        - name: PGDATA
          value: /var/lib/postgresql/data/pgdata
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
        - name: initdb
          mountPath: /docker-entrypoint-initdb.d
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
      volumes:
      - name: initdb
        configMap:
          name: fanclub-db-init
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: {{ .Values.db.storageClass }}
      resources:
        requests:
          storage: {{ .Values.db.storage }}

本書ラボの既存 PVC は pgdata の所有者がすでに 999 なので、fsGroup が無くてもファイルシステムとしては動きます。それでも書くのは、読者が新規に構築したときに再現するためです。なお PSS の判定としては runAsNonRoot: true が別途必須で、runAsUser を非 0 にするだけでは Restricted を満たしません（拒否メッセージの runAsNonRoot != true がそれです）。

backend — 足りないのは initContainer 2 本#

backend の Deployment には、第6回で入れた Pod レベルの seccompProfile: RuntimeDefault と、backend コンテナの securityContext（runAsNonRoot: true / runAsUser: 10001 / readOnlyRootFilesystem: true / allowPrivilegeEscalation: false / capabilities.drop: ["ALL"]）が既にあります。

足りないのは initContainers 2 本のコンテナレベル指定です（実測で両方とも空）。

ネイティブサイドカーは、initContainers に restartPolicy: Always を付けたコンテナのことです。init として先に起動し、本体と並走し続けます（v1.29 で安定化しました）。

両方に足す securityContext：

          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

log-shipper に uid 10001 を指定する理由は、backend（uid 10001）が emptyDir applog へ書いたファイルを tail -F するからです。同じ uid でないと読めません。 「非 root にする」だけでは足りず、どの uid にするかがボリューム共有の成否を決めます。

マージ後の ~/gitops/gitops-fanclub/base/backend-deployment.yaml のうち、initContainers の部分：

      securityContext:
        seccompProfile:
          type: RuntimeDefault
      initContainers:
      - name: wait-for-db
        image: busybox:1.37
        command: ["sh","-c","until nslookup fanclub-db.fanclub.svc.cluster.local >/dev/null 2>&1; do echo waiting; sleep 2; done; echo resolved"]
        securityContext:
          runAsNonRoot: true
          runAsUser: 10001
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
      - name: log-shipper
        image: busybox:1.37
        restartPolicy: Always
        command: ["sh","-c","echo sidecar; tail -F /var/log/app/app.log 2>/dev/null || sleep infinity"]
        securityContext:
          runAsNonRoot: true
          runAsUser: 10001
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: applog
          mountPath: /var/log/app

Pod レベルの securityContext（seccompProfile）は第6回で入れたものがそのまま残ります。足すのは initContainers 2 本のブロックだけです。containers の backend は第1巻第15回の指定がそのまま Restricted を満たしています。

logcollector と CronJob — 制約が緩い 2 つ#

DaemonSet fanclub-logcollector に足すもの（Pod レベルとコンテナレベル）：

    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: logcollector
        image: busybox:1.37
        command:
        - sh
        - -c
        - 'echo "log collector started on $(hostname)"; while true; do sleep 3600; done'
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]

CronJob fanclub-report に足すもの：

        spec:
          restartPolicy: OnFailure
          securityContext:
            runAsNonRoot: true
            runAsUser: 999
            runAsGroup: 999
            seccompProfile:
              type: RuntimeDefault
          containers:
          - name: report
            image: {{ .Values.db.image.repository }}:{{ .Values.db.image.tag }}
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: ["ALL"]

CronJob の uid を 999 にしているのは、イメージが postgres:18 だからです（psql を実行するだけなので他の uid でも動きますが、イメージに存在するユーザに合わせておくほうが素直です）。

見落としやすい 6 つ目 —— Helm フックの Job#

Helm フックの Job に足すもの：

    spec:
      restartPolicy: Never
      securityContext:
        runAsNonRoot: true
        runAsUser: 999
        runAsGroup: 999
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: migrate
        image: {{ .Values.db.image.repository }}:{{ .Values.db.image.tag }}
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]

やってみよう⑤：fanclub を Restricted 化して enforce を貼る#

$ k -n fanclub get deploy fanclub-frontend -o yaml > d.yaml
$ vi d.yaml
$ k apply -f d.yaml
$ k -n fanclub get pod -l app=fanclub-frontend

対象は k8s-ops 上の Git リポジトリと Helm chart です。

ステップ1：正本を確認する#

前の節の 2 コマンド（custom-columns による annotation の確認と、ArgoCD Application の jsonpath）を実行し、backend / frontend は Git、db / logcollector / CronJob は Helm chart であることを確かめます。

ステップ2：Git 側（backend / frontend）を直す#

~/gitops/gitops-fanclub/base/backend-deployment.yaml と frontend-deployment.yaml に、前の節の securityContext と emptyDir を足して commit / push します。

実行コマンド（k8s-ops 上・developer・初回のみ）：

$ git config --global user.name "developer"
$ git config --global user.email "developer@example.com"

実行コマンド（k8s-ops 上・developer・~/gitops/gitops-fanclub に移動してから）：

$ export no_proxy="$no_proxy,k8s-registry"

no_proxy に k8s-registry を足さないと Gitea への push が Squid 経由になり 403 で止まります（第6回で確定した作法です）。

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

$ git add base/backend-deployment.yaml base/frontend-deployment.yaml
$ git commit -m "Apply PSS Restricted securityContext to backend initContainers and frontend"
$ git push origin main

実行結果：

[main 77114fe] Apply PSS Restricted securityContext to backend initContainers and frontend
 2 files changed, 29 insertions(+)
remote: . Processing 1 references
remote: Processed 1 references in total
To http://k8s-registry:3000/developer/gitops-fanclub.git
   9b487a9..77114fe  main -> main

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

$ kubectl -n argocd get application fanclub-api-prod

実行結果（同期が終わったあと）：

NAME               SYNC STATUS   HEALTH STATUS
fanclub-api-prod   Synced        Healthy

本書ラボでは push から frontend の runAsUser: 101 がクラスタに現れるまで 76 秒でした（ArgoCD の既定ポーリング間隔）。backend はローリング更新に時間がかかり、3 Pod が 2/2 に揃うまで約 10 分です（Payara の起動時間 + maxUnavailable: 0）。

実行コマンド（完了まで待つ場合・k8s-ops 上・developer）：

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

実行結果：

deployment "fanclub-backend" successfully rolled out

次のステップへ進む前に、ここで Synced / Healthy になるのを待ってください。 順序には理由があります（このあとのガードレール枠で説明します）。

ステップ3：Helm chart 側（db / logcollector / CronJob）を直す#

~/fanclub-chart/templates/ の 3 ファイル（db-statefulset.yaml / daemonset.yaml / cronjob.yaml）に、前の節の securityContext を足します。

あわせて ~/fanclub-chart/templates/backend-deployment.yaml と frontend-deployment.yaml も、Git 側と同じ内容へそろえます。

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

$ cd ~

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

$ helm upgrade fanclub ./fanclub-chart --namespace fanclub --set gateway.enabled=true --set frontend.image.tag=1.0.0 --set backend.replicaCount=3 --set frontend.replicaCount=2

実行結果（この形では失敗します）：

Error: UPGRADE FAILED: conflict occurred while applying object fanclub/allow-frontend-from-gateway networking.k8s.io/v1, Kind=NetworkPolicy: Apply failed with 1 conflict: conflict with "kubectl-client-side-apply" using networking.k8s.io/v1: .spec.ingress && conflict occurred while applying object fanclub/fanclub-quota /v1, Kind=ResourceQuota: Apply failed with 6 conflicts: conflicts with "argocd-controller" using v1:
- .spec.hard.limits.cpu
- .spec.hard.limits.memory
- .spec.hard.persistentvolumeclaims
- .spec.hard.pods
- .spec.hard.requests.cpu
- .spec.hard.requests.memory

衝突を承知で Helm に書かせるには --force-conflicts を付けます。

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

$ helm upgrade fanclub ./fanclub-chart --namespace fanclub --set gateway.enabled=true --set frontend.image.tag=1.0.0 --set backend.replicaCount=3 --set frontend.replicaCount=2 --force-conflicts

実行結果：

Release "fanclub" has been upgraded. Happy Helming!
NAME: fanclub
LAST DEPLOYED: Mon Jul 27 22:00:46 2026
NAMESPACE: fanclub
STATUS: deployed
REVISION: 7
DESCRIPTION: Upgrade complete
TEST SUITE: None

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

$ kubectl -n fanclub get deploy,sts,ds

実行結果：

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/fanclub-backend    3/3     3            3           43h
deployment.apps/fanclub-frontend   2/2     2            2           43h

NAME                          READY   AGE
statefulset.apps/fanclub-db   1/1     43h

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/fanclub-logcollector   2         2         2       2            2           <none>          43h

backend 3 / frontend 2 / db 1 / logcollector 2 が揃っています。 レプリカ数を明示したので巻き戻りは起きませんでした。

ステップ4：全 Pod が Restricted 準拠になったことを dry-run で確認する#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest --dry-run=server

実行結果：

namespace/fanclub labeled (server dry run)

警告 0 行。 やってみよう① で 3 行出ていたものが消えました。ここが本演習の合格条件です。0 行を確認せずに次のステップへ進まないでください。

ステップ5：enforce を貼る#

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

$ kubectl label ns fanclub pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest

実行結果：

namespace/fanclub labeled

警告が 1 行も出ません。 やってみよう② では警告が 3 行出ていました。違反が無くなった証拠です。

ステップ6：壊れていないことを確かめる#

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

$ kubectl -n fanclub get pod

実行結果：

NAME                                READY   STATUS    RESTARTS   AGE
fanclub-backend-67dc44fc95-6pwnr    2/2     Running   0          5m22s
fanclub-backend-67dc44fc95-qzdsj    2/2     Running   0          20m
fanclub-backend-67dc44fc95-vv2hn    2/2     Running   0          23m
fanclub-db-0                        1/1     Running   0          17m
fanclub-frontend-69d8fc6d88-59w7t   1/1     Running   0          103s
fanclub-frontend-69d8fc6d88-9xf6w   1/1     Running   0          104s
fanclub-logcollector-jxrf9          1/1     Running   0          16m
fanclub-logcollector-t7qbd          1/1     Running   0          16m

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

$ kubectl -n fanclub get deploy,sts,ds

実行結果：

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/fanclub-backend    3/3     3            3           43h
deployment.apps/fanclub-frontend   2/2     2            2           43h

NAME                          READY   AGE
statefulset.apps/fanclub-db   1/1     43h

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/fanclub-logcollector   2         2         2       2            2           <none>          43h

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

$ kubectl -n longhorn-system get volumes.longhorn.io

実行結果：

NAME                                       DATA ENGINE   STATE      ROBUSTNESS   SCHEDULED   SIZE         NODE        AGE
pvc-21281d08-c435-4033-a67d-c95bce442936   v1            attached   healthy                  5368709120   k8s-wl-02   43h
pvc-226c8f31-f346-4327-aec7-4f3f39707a4b   v1            attached   healthy                  1073741824   k8s-wl-02   43h
pvc-e9e00c36-64a9-4ff2-b3b0-f21511a2257e   v1            attached   healthy                  5368709120   k8s-wl-02   43h
pvc-f342237e-464a-4be2-99c9-84cc71ea7d17   v1            attached   healthy                  2147483648   k8s-wl-02   43h

4 ボリュームすべて attached healthy です。fsGroup: 999 を足しても既存のデータには影響していません。

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

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

実行結果：

200

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

$ curl -sk --noproxy '*' https://fanclub.local/api/members

実行結果（先頭のみ）：

[{"createdAt":"2026-07-25T14:28:03.572932","email":"hanako@example.com","id":1,"name":"鈴木花子","plan":"standard"}

会員データが読めています。 DB を uid 999 で動かしても、Longhorn の既存データはそのまま使えました。

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

$ kubectl -n fanclub rollout restart deploy/fanclub-frontend

実行結果：

deployment.apps/fanclub-frontend restarted

40 秒ほど待って確認します。

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

$ kubectl -n fanclub get pod -l app=fanclub-frontend

実行結果：

NAME                                READY   STATUS    RESTARTS   AGE
fanclub-frontend-69d8fc6d88-59w7t   1/1     Running   0          39s
fanclub-frontend-69d8fc6d88-9xf6w   1/1     Running   0          40s

やってみよう② では 1 つも作られなかった Pod が、今度は 40 秒で 2 つとも Running になりました。 UP-TO-DATE も 2 のままです。同じ enforce=restricted の下で、結果が反対になりました。

ステップ7：弾かれることを確かめる#

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

$ kubectl -n fanclub run probe-frontend --image=k8s-registry:5000/fanclub-frontend:1.0.0

実行結果：

Error from server (Forbidden): pods "probe-frontend" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "probe-frontend" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "probe-frontend" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "probe-frontend" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "probe-frontend" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

同じイメージでも、securityContext を書かずに kubectl run で作った Pod は拒否されます。 守られているのは namespace であって、イメージではありません。

Deployment 経由で作られる Pod は通り、素の kubectl run は弾かれる。 これが「namespace 全体を Restricted に上げた」状態です。

ステップ8：後片付け#

本演習の変更（fanclub の Restricted 化）は残します。第9回以降のラボはこの状態を前提にします。

ValidatingAdmissionPolicy（CEL）— 素朴な式は取りこぼす#

PSS は「Pod のセキュリティ姿勢」を強制します。しかし 「latest タグを禁止する」「許可レジストリ以外を拒否する」といった組織固有のルールは表現できません（後の節で整理します）。

ValidatingAdmissionPolicy（VAP） は Kubernetes 組込の Admission ポリシーで、CEL で条件を書きます。外部コンポーネントが要りません。

CEL（Common Expression Language）は Google 発の式言語で、副作用の無い短い判定式を書くために設計されています。Kubernetes は VAP や CRD の検証などで採用しています。

まず素朴に書いてみる#

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: disallow-latest-tag
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.containers.all(c, !c.image.endsWith(':latest'))"
      message: "latest タグの使用は禁止されています"

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: disallow-latest-tag-binding
spec:
  policyName: disallow-latest-tag
  validationActions: ["Deny"]
  matchResources:
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: policy-probe

ポリシー本体（ValidatingAdmissionPolicy）と適用先（ValidatingAdmissionPolicyBinding）が分かれているのが VAP の構造です。ポリシーを書いただけでは何も起きません。Binding で validationActions: ["Deny"] を書いて初めて拒否になります。

上の Binding は policy-probe という namespace だけを対象にしています。この namespace は演習用に作ります（kubectl create ns policy-probe）。PSA ラベルは貼りません——理由はこの節の最後で説明します。

この素朴な式を実機で試すと、次のようになりました。

拒否されたときの実行結果：

The pods "vap-latest" is invalid: : ValidatingAdmissionPolicy 'disallow-latest-tag' with binding 'disallow-latest-tag-binding' denied request: latest タグの使用は禁止されています

取りこぼしを潰した式（実機で全ケース検証済み）#

ポリシー本体を次の形へ差し替えます。variables と validations が変わり、それ以外は同じです。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: disallow-latest-tag
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  variables:
    - name: allContainers
      expression: "object.spec.containers + (has(object.spec.initContainers) ? object.spec.initContainers : [])"
  validations:
    - expression: "variables.allContainers.all(c, c.image.split('/')[c.image.split('/').size() - 1].contains(':') && !c.image.endsWith(':latest'))"
      message: "イメージはタグを明示し latest を使わないこと"

metadata / failurePolicy / matchConstraints は素朴版と同じです。variables ブロックを足し、validations の式を差し替えるだけで、上の YAML 全量をそのまま kubectl apply -f できます（Binding は変更不要です）。

実測結果は次のとおりです。6 ケースすべて検証済みです。

式の設計を 3 点に分解します。

1. variables —— containers と initContainers を連結した配列を作ります。has() で存在確認しないと、initContainers が無い Pod で式がエラーになります
2. split('/') の最後の要素だけを見る —— イメージ名は <レジストリ>/<パス>/<名前>:<タグ> の形なので、タグがあるとすれば最後のスラッシュより後ろにあります
3. contains(':') だけで判定してはいけません —— 本書ラボのレジストリは k8s-registry:5000 で、ホスト名にコロンが含まれます。 素朴に image.contains(':') と書くと、タグを省略した k8s-registry:5000/fanclub-backend を「タグあり」と誤判定します

評価順序の罠#

enforce=restricted の namespace で VAP を試すと、PodSecurity が先に拒否して VAP のメッセージが表示されません（実測）。

型チェックと Mutating 版#

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

$ kubectl get validatingadmissionpolicy disallow-latest-tag -o jsonpath='{.status.typeChecking}'

実行結果：

{}

空のオブジェクトは「型エラー無し」という意味です。式の書き方を間違えると、ここにエラーが入ります。

status.typeChecking は VAP の強みです。 CEL 式に型の誤りがあると、Pod を作る前に、ポリシーを apply した時点で分かります。 Gatekeeper の Rego にはこの仕組みがありません（次の節の落とし穴に直結します）。

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

$ kubectl api-resources | grep -i mutatingadmissionpolicy

実行結果：

mutatingadmissionpolicies                              admissionregistration.k8s.io/v1      false        MutatingAdmissionPolicy
mutatingadmissionpolicybindings                        admissionregistration.k8s.io/v1      false        MutatingAdmissionPolicyBinding

v1.36 のラボには MutatingAdmissionPolicy / MutatingAdmissionPolicyBinding も admissionregistration.k8s.io/v1 で存在します（実測）。CEL 系が「拒む」だけでなく「書き換える」まで組込で持つようになりました。 外部コンポーネントを入れないと mutate できない、という前提が 1 つ崩れたという意味で、選択の地図が変わりつつあります。

OPA Gatekeeper — apply が通ってもポリシーが効いていないことがある#

Gatekeeper は ConstraintTemplate（Rego でルールを定義し、専用の CRD を生やす）と Constraint（生えた CRD のインスタンスとして、どこに適用するかを書く）の二段構えです。

ルールを書く言語は Rego です。OPA（Open Policy Agent）のポリシー記述言語で、宣言的ですが独自文法を持ち、v0 と v1 で書き方が変わっています。 この「変わっている」ことが、本節最大の落とし穴の正体です。

導入#

コマンド（alma-proxy 上・root・この節では打ちません）：

# grep -c "open-policy-agent.github.io" /etc/squid/whitelist.txt

そのときの実行結果：

0

0 ＝ 1 行もありません。このままでは helm repo add が Squid に拒否されます。

コマンド（alma-proxy 上・root・この節では打ちません）：

# cp /etc/squid/whitelist.txt /etc/squid/whitelist.txt.pre08.bak
# echo "open-policy-agent.github.io" >> /etc/squid/whitelist.txt
# systemctl reload squid

コマンド（確認・alma-proxy 上・root・この節では打ちません）：

# grep -c "open-policy-agent.github.io" /etc/squid/whitelist.txt

そのときの実行結果：

1

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

そのときの実行結果：

"gatekeeper" has been added to your repositories

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ helm install gatekeeper gatekeeper/gatekeeper --namespace gatekeeper-system --create-namespace --version 3.23.0

そのときの実行結果：

NAME: gatekeeper
LAST DEPLOYED: Mon Jul 27 22:24:41 2026
NAMESPACE: gatekeeper-system
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ kubectl -n gatekeeper-system get pod

そのときの実行結果：

NAME                                            READY   STATUS    RESTARTS   AGE
gatekeeper-audit-b9d5f797b-nm5xp                1/1     Running   0          28s
gatekeeper-controller-manager-5b6f9b6b9-469tq   1/1     Running   0          28s
gatekeeper-controller-manager-5b6f9b6b9-pqnb5   1/1     Running   0          28s
gatekeeper-controller-manager-5b6f9b6b9-s69nv   0/1     Running   0          28s

本書ラボでは 4 Pod（controller-manager 3 + audit 1）がすべて Running になるまで 40 秒でした。0/1 Running の Pod は readiness を待っているだけなので、数秒待てば揃います。

--version 3.23.0 は必ず付けてください。先頭に v は付けません（chart バージョンの表記は 3.23.0 です）。バージョンを省くとその時点の最新が入り、記事の出力と食い違います。

コマンド（k8s-ops 上・developer・やってみよう③ ステップ4 と同じもの）：

$ kubectl get ns -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce,VERSION:.metadata.labels.pod-security\.kubernetes\.io/enforce-version'

そのときの実行結果（ラベルが付いている行の抜粋）：

NAME                 ENFORCE      VERSION
fanclub              restricted   latest
gatekeeper-system    restricted   v1.24
local-path-storage   privileged   latest
longhorn-system      privileged   latest
metallb-system       privileged   latest
monitoring           privileged   latest
velero               privileged   latest

gatekeeper-system に restricted / v1.24 が入っています。latest ではなく v1.24 と固定されているのは、chart の作者が「この版で検証した」と宣言しているからです。バージョンを固定するほうが、クラスタを上げたときに勝手に厳しくならない——ここは設計判断が分かれる点です。

最大の落とし穴 — apply は通るのにポリシーが効いていない#

まず素朴なルールを書きます。ConstraintTemplate（Rego v0 記法）です。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sdisallowlatesttag
spec:
  crd:
    spec:
      names:
        kind: K8sDisallowLatestTag
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdisallowlatesttag
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          endswith(container.image, ":latest")
          msg := sprintf("コンテナ %v は latest タグを使用しています", [container.name])
        }

Constraint（テンプレートが生やした CRD のインスタンス）：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowLatestTag
metadata:
  name: disallow-latest-tag
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Constraint は namespace に属さないクラスタスコープのリソースです。-n を付けても無視されます——エラーは出ず、metadata.namespace が空のまま作られるので、「namespace を指定したつもり」で全 namespace に効いてしまいます。 上の例は spec.match.namespaces を書いていないのですべての namespace の Pod が対象になります。絞るときは必ず spec.match.namespaces に書いてください。

ここで rego: の 2 行目に import rego.v1 を足すと何が起きるか。実測では次のようになりました。

• kubectl apply は成功する
• しかしポリシーは 1 件も効かない
• エラーは status.byPod[].errors にしか出ない

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ kubectl get constrainttemplate k8sdisallowlatesttag -o jsonpath='{.status}'

実行結果（import rego.v1 を書いた場合・抜粋）：

"errors": [{"code": "ingest_error",
  "message": "Could not ingest Rego: invalid ConstraintTemplate: 2 errors occurred:\ntemplate:3: rego_parse_error: `if` keyword is required before rule body\ntemplate:3: rego_parse_error: `contains` keyword is required for partial set rules"}]

実行結果（正しい場合・抜粋）：

{
    "byPod": [
        {
            "id": "gatekeeper-audit-b9d5f797b-nm5xp",
            "observedGeneration": 1,
            "operations": [
                "audit",
                "generate",
                "mutation-status",
                "status"
            ],
            "templateUID": "1f5cc8f2-c7c3-4765-8e87-ed93cead4837"
        }
    ]
}

実行結果（import rego.v1 を書いた場合・byPod[0] のみ）：

{
    "errors": [
        {
            "code": "ingest_error",
            "message": "Could not ingest Rego: invalid ConstraintTemplate: 2 errors occurred:\ntemplate:3: rego_parse_error: `if` keyword is required before rule body\ntemplate:3: rego_parse_error: `contains` keyword is required for partial set rules"
        }
    ],
    "id": "gatekeeper-audit-b9d5f797b-nm5xp",
    "observedGeneration": 1,
    "operations": [
        "audit",
        "generate",
        "mutation-status",
        "status"
    ],
    "templateUID": "782db48c-6135-4c20-ae8f-e23be23cafe1"
}

違いは errors の有無だけです。kubectl apply はどちらも created を返します。

取りこぼしを潰した Rego（実機で全ケース検証済み）#

素朴な Rego は、CEL の素朴版とまったく同じ取りこぼし方をします。タグ省略（nginx）と initContainers が素通りします。 CEL 版と同じ判定精度を Rego で実装すると次のようになります。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequireexplicittag
spec:
  crd:
    spec:
      names:
        kind: K8sRequireExplicitTag
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequireexplicittag
        violation[{"msg": msg}] {
          container := input.review.object.spec[containers][_]
          containers_field(containers)
          not has_explicit_tag(container.image)
          msg := sprintf("コンテナ %v のイメージ %v はタグが明示されていないか latest です", [container.name, container.image])
        }
        containers_field("containers")
        containers_field("initContainers")
        has_explicit_tag(image) {
          parts := split(image, "/")
          last := parts[count(parts) - 1]
          contains(last, ":")
          not endswith(image, ":latest")
        }

対応する Constraint（kind が K8sRequireExplicitTag に変わります）：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequireExplicitTag
metadata:
  name: require-explicit-tag
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces: ["policy-probe"]

Rego の書き方を 3 点に分解します。

1. input.review.object.spec[containers][_] —— containers を変数にして spec のキーを動的に選びます
2. containers_field("containers") と containers_field("initContainers") の 2 行が、その変数に入りうる値を定義します。この 2 行だけで両方を走査できます
3. has_explicit_tag は CEL 版と同じ考え方で、split(image, "/") の最後の要素にコロンがあるかを見ます

• spec[containers][_] と containers_field("containers") / containers_field("initContainers") の 2 本の規則で、containers と initContainers の両方を走査します（Rego v0 の書き方です）
• split(image, "/") の最後の要素だけを見るのは CEL 版と同じ考え方です
• CEL 版と同じ 2 つの抜け（ephemeralContainers とダイジェスト指定）はこちらにも残っています

効いているかを確かめる 2 つのコマンド#

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ kubectl get k8sdisallowlatesttag disallow-latest-tag -o jsonpath='{.status.byPod[0].enforced}'

実行結果：

true

enforced: true になって初めて効きます。 Constraint を作った直後は false や空のことがあるので、20 秒ほど待ってから確認してください。

実際に拒否されたときの実行結果：

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [disallow-latest-tag] コンテナ gk-latest は latest タグを使用しています

3 つの拒否メッセージの形を並べて覚えてください。 試験でも実務でも、メッセージの形だけで「どの層に弾かれたか」が分かります。

fail-open が既定#

fail-open / fail-closed は、ポリシー判定の仕組みが落ちたときにどちらへ倒れるかの設計です。通す側に倒れるのが fail-open、拒む側に倒れるのが fail-closed です。

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ kubectl get validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -o custom-columns='WEBHOOK:.webhooks[*].name,FAILUREPOLICY:.webhooks[*].failurePolicy'

実行結果：

WEBHOOK                                                     FAILUREPOLICY
validation.gatekeeper.sh,check-ignore-label.gatekeeper.sh   Ignore,Fail

custom-columns の [*] は複数の値をカンマで並べるので、2 つの webhook が並んだ 1 行として返ります。整理すると次のようになります。

本番で Gatekeeper を Fail に変えるなら、可用性を先に設計してください。chart の既定で controller-manager は 3 レプリカです（実測で 4 Pod のうち 3 つ）。そのうえで次の 3 点を決めます。

• PodDisruptionBudget —— ノードのドレイン時に全レプリカが同時に落ちないようにする
• topologySpreadConstraints —— 3 レプリカが同じノードに寄らないようにする。1 ノードに 3 つ載っていれば、レプリカ数は気休めにしかならない
• webhook の namespaceSelector —— kube-system のような復旧に必要な namespace を除外しておく。ここを閉じたまま Gatekeeper が落ちると、Gatekeeper を直すための Pod も作れません

Gatekeeper にしかできないこと — audit（既存リソースの棚卸し）#

Gatekeeper の audit は、すでにクラスタにあるリソースを Constraint に照らして定期的に評価し、違反を status.violations に書きます。VAP にはこの機能がありません（VAP は Admission のタイミングでしか評価しません）。

コマンド（k8s-ops 上・developer・この節では打ちません）：

$ kubectl get k8srequireexplicittag require-explicit-tag -o jsonpath='{.status.violations}'

実行結果（違反が 1 件ある状態・本書ラボで nginx:latest の Pod を先に作って確認したもの）：

[{"enforcementAction":"deny","group":"","kind":"Pod","message":"コンテナ legacy-app のイメージ nginx:latest はタグが明示されていないか latest です","name":"legacy-app","namespace":"gk-audit","version":"v1"}]

Error from server (Forbidden): error when creating "legacy.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [disallow-latest-tag] コンテナ legacy-app は latest タグを使用しています

件数だけを見るなら status.totalViolations が使えます。本書ラボの平常時は 0 件です（クラスタ内に :latest の Pod がありません）。違反 Pod を作ってから totalViolations が 1 に変わるまで 50 秒かかりました（audit の既定間隔は 60 秒）。

反映は即座ではありません。 audit の既定間隔が 60 秒なので、「違反リソースを作った直後に見ても 0 のまま」という時間差があります。ダッシュボードに出すときは、この遅延を前提に読んでください。

やってみよう⑥：latest タグ禁止を VAP と Gatekeeper の両方で実装する#

対象は k8s-ops 上の kubectl と検証用 namespace です。

ステップ1：検証用の namespace を作る（PSS ラベルは貼らない）#

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

$ kubectl create ns policy-probe

実行結果：

namespace/policy-probe created

PSS ラベルを貼らない理由は、enforce=restricted の namespace では PodSecurity が先に拒否して VAP や Gatekeeper のメッセージが出ないからです。ポリシー単体の動作を確かめるには、手前に何も無い namespace が要ります。

ステップ2：VAP を素朴な式で作り、取りこぼしを確認する#

前の節の「素朴な式」の VAP と Binding を apply し、3 パターンを試します。

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

$ kubectl -n policy-probe run vap-latest --image=nginx:latest

実行結果：

The pods "vap-latest" is invalid: : ValidatingAdmissionPolicy 'disallow-latest-tag' with binding 'disallow-latest-tag-binding' denied request: latest タグの使用は禁止されています

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

$ kubectl -n policy-probe run vap-notag --image=nginx

実行結果：

pod/vap-notag created

通ってしまいました。 nginx の実体は nginx:latest です。

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

$ kubectl -n policy-probe run vap-init --image=nginx:1.27-alpine --overrides='{"spec":{"initContainers":[{"name":"init","image":"busybox:latest","command":["sh","-c","true"]}]}}'

実行結果：

pod/vap-init created

これも通ってしまいました。 object.spec.containers しか見ていないので、initContainers は素通りです。

ステップ3：式を差し替えて全ケースを潰す#

前の節の「取りこぼしを潰した式」へ variables と validations を差し替え、6 パターン（nginx:latest / nginx / nginx:1.27-alpine / k8s-registry:5000/fanclub-backend:0.3.2 / k8s-registry:5000/fanclub-backend / initContainers の busybox:latest）を試します。

実行結果（6 パターン）：

nginx:latest
The pods "vap-t" is invalid: : ValidatingAdmissionPolicy 'disallow-latest-tag' with binding 'disallow-latest-tag-binding' denied request: イメージはタグを明示し latest を使わないこと

nginx
The pods "vap-t" is invalid: : ValidatingAdmissionPolicy 'disallow-latest-tag' with binding 'disallow-latest-tag-binding' denied request: イメージはタグを明示し latest を使わないこと

nginx:1.27-alpine
pod/vap-t created

k8s-registry:5000/fanclub-backend:0.3.2
pod/vap-t created

k8s-registry:5000/fanclub-backend
The pods "vap-t" is invalid: : ValidatingAdmissionPolicy 'disallow-latest-tag' with binding 'disallow-latest-tag-binding' denied request: イメージはタグを明示し latest を使わないこと

initContainers に busybox:latest
The pods "vap-i" is invalid: : ValidatingAdmissionPolicy 'disallow-latest-tag' with binding 'disallow-latest-tag-binding' denied request: イメージはタグを明示し latest を使わないこと

k8s-registry:5000/fanclub-backend:0.3.2 が通ることが本演習の要です。レジストリのポート番号のコロンを、タグのコロンと取り違えていないことを、この 1 行が証明しています。

ステップ4：Gatekeeper を導入して同じルールを Rego で書く#

前の節の手順（whitelist 追加 → helm repo add → helm install --version 3.23.0 → ConstraintTemplate → Constraint）を実施します。

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

$ kubectl delete validatingadmissionpolicybinding disallow-latest-tag-binding

実行結果：

validatingadmissionpolicybinding.admissionregistration.k8s.io "disallow-latest-tag-binding" deleted

素朴な Rego（k8sdisallowlatesttag）を適用したときの実行結果：

nginx:latest
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [disallow-latest-tag] コンテナ gk-latest は latest タグを使用しています

nginx
pod/gk-notag created

initContainers に busybox:latest
pod/gk-init created

CEL の素朴版とまったく同じ取りこぼし方です。言語が違っても、見ている場所が同じなら結果も同じになります。

取りこぼしを潰した Rego（k8srequireexplicittag）へ差し替えたときの実行結果（6 パターン）：

nginx:latest
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-explicit-tag] コンテナ gkr のイメージ nginx:latest はタグが明示されていないか latest です

nginx
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-explicit-tag] コンテナ gkr のイメージ nginx はタグが明示されていないか latest です

nginx:1.27-alpine
pod/gkr created

k8s-registry:5000/fanclub-backend:0.3.2
pod/gkr created

k8s-registry:5000/fanclub-backend
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-explicit-tag] コンテナ gkr のイメージ k8s-registry:5000/fanclub-backend はタグが明示されていないか latest です

initContainers に busybox:latest
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-explicit-tag] コンテナ i のイメージ busybox:latest はタグが明示されていないか latest です

CEL 版とまったく同じ 6 つの判定結果になりました。最後の 1 行では、違反しているコンテナ名が i（initContainer の名前）と出ています。どのコンテナが原因かまで分かるのは、Rego の msg に container.name を入れているからです。

ステップ5：わざと import rego.v1 を書いて壊れ方を見る#

ConstraintTemplate の rego: の 2 行目に import rego.v1 を足して apply し、apply は成功するのにポリシーが効かないことを確認します。

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

$ kubectl get constrainttemplate k8sdisallowlatesttag -o jsonpath='{.status}'

実行結果（byPod[0] のみ）：

{
    "errors": [
        {
            "code": "ingest_error",
            "message": "Could not ingest Rego: invalid ConstraintTemplate: 2 errors occurred:\ntemplate:3: rego_parse_error: `if` keyword is required before rule body\ntemplate:3: rego_parse_error: `contains` keyword is required for partial set rules"
        }
    ],
    "id": "gatekeeper-audit-b9d5f797b-nm5xp",
    "observedGeneration": 1,
    "operations": [
        "audit",
        "generate",
        "mutation-status",
        "status"
    ],
    "templateUID": "782db48c-6135-4c20-ae8f-e23be23cafe1"
}

kubectl apply は created を返していました。 エラーはここにしか出ません。

次のステップへ進む前に必ず戻してください。 import rego.v1 の 1 行を削って apply し直します。

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

$ kubectl apply -f k8sdisallowlatesttag.yaml

実行結果：

constrainttemplate.templates.gatekeeper.sh/k8sdisallowlatesttag configured

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

$ kubectl get constrainttemplate k8sdisallowlatesttag -o jsonpath='{.status.byPod[0].errors}'

実行結果（何も返らなければ復旧しています）：

（出力はありません）

errors が空になったことを確認してから次へ進んでください。 壊れたままだと、次のステップの enforced は true になりません。

ステップ6：enforced と violations を確認する#

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

$ kubectl get k8sdisallowlatesttag disallow-latest-tag -o jsonpath='{.status.byPod[0].enforced}'

実行結果：

true

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

$ kubectl get k8sdisallowlatesttag disallow-latest-tag -o jsonpath='{.status.totalViolations}'

実行結果：

0

0 です。 ステップ2 で作った vap-notag（イメージ nginx）はまだ policy-probe に残っていますが、この Constraint は素朴版で :latest で終わる文字列しか見ていないので、違反として数えられません。「audit の件数が 0 だから安全」ではなく、「そのポリシーが見ている範囲で 0」という読み方をしてください。

ステップ7：後片付け#

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

$ kubectl delete ns policy-probe

ValidatingAdmissionPolicyBinding（disallow-latest-tag-binding）は、ステップ4 の冒頭ですでに削除しています——Gatekeeper の拒否メッセージを見るために、手前で拒否していた VAP の Binding を外しました。ここで改めて打つ必要はありません。 打っても NotFound が返るだけで、この後の実行結果にも現れません。

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

$ kubectl delete validatingadmissionpolicy disallow-latest-tag

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

$ kubectl delete k8sdisallowlatesttag disallow-latest-tag

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

$ kubectl delete constrainttemplate k8sdisallowlatesttag

ステップ4 で「取りこぼしを潰した Rego」を別テンプレートとして適用した場合は、次の 2 つも削除します。

$ kubectl delete k8srequireexplicittag require-explicit-tag
$ kubectl delete constrainttemplate k8srequireexplicittag

実行結果（本書ラボでまとめて実行したもの）：

k8srequireexplicittag.constraints.gatekeeper.sh "require-explicit-tag" deleted
constrainttemplate.templates.gatekeeper.sh "k8srequireexplicittag" deleted
constrainttemplate.templates.gatekeeper.sh "k8sdisallowlatesttag" deleted
validatingadmissionpolicy.admissionregistration.k8s.io "disallow-latest-tag" deleted
namespace "policy-probe" deleted

実行コマンド（残っていないことの確認・k8s-ops 上・developer）：

$ kubectl get constrainttemplate
$ kubectl get validatingadmissionpolicy
$ kubectl get validatingadmissionpolicybinding

実行結果：

No resources found
No resources found
No resources found

PSS で足りない制約と、ポリシーエンジン 4 種の比較#

PSS で表現できないもの#

4 種の比較表#

Kyverno の位置づけ（記法の対比のみ・ラボには導入しない）#

• ポリシーを YAML で書けるのが最大の特徴です。Rego の学習コストが不要で、Kubernetes ネイティブな書き味になります
• mutate（既定値の注入）と generate（付随リソースの自動生成）を標準で持ち、Gatekeeper より「直す」方向が得意です
• CNCF プロジェクトとして広く使われていますが、CKS 公式コンピテンシーは Kyverno を名指ししていません。 試験対策としては PSS + VAP + Gatekeeper で足ります

Kyverno のポリシー例です。記法の対比のためだけに載せており、本書ラボには導入していません。実機検証もしていません。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "latest タグは使用できません"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

試験対策上の優先度は PSS > VAP・Gatekeeper > Kyverno です。Kyverno は「そういう選択肢がある」ところまで知っていれば足ります。

暗記必須コマンド（PSA / AdmissionConfiguration / VAP / Gatekeeper）#

ラボ v1.36.3 と試験 v1.35 で何が変わるか#

本書ラボは Kubernetes v1.36.3、CKS 試験環境は v1.35 です。本回の内容に関わる差分は 2 点あります。

• enforce-version: latest の解決先が違います。 ラボで latest と書くと v1.36 のプロファイル定義に、試験環境で書くと v1.35 の定義になります。本回で扱った範囲の要件は両者で変わりませんが、「latest はクラスタのバージョンに引きずられる」ことは意識してください。試験で明示的にバージョンを指定するよう求められた場合は、enforce-version: v1.35 のように書けます（ラボで受理されることは実測済みです）
• MutatingAdmissionPolicy は v1.36 のラボで admissionregistration.k8s.io/v1 として確認したものです。 試験環境（v1.35）で同じ API バージョンで存在するかは確認していません。 試験の解答に使わないでください

LF は Kubernetes のリリースから概ね 4〜8 週間で試験環境を最新マイナーへ整合させます。受験前に必ず公式の試験バージョンを確認してください。

まとめ#

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

• PSP は v1.25 で削除済み。 現在は PSS（3 プロファイル）+ PSA（3 モード・組込 Admission）の 2 本立て
• 既存 Pod の違反を壊さずに数えられるのは enforce ラベル + --dry-run=server だけ。 warn / audit の dry-run では 1 行も出ない
• warn は Deployment を書き換えた瞬間に効く。 enforce は Pod が作られる瞬間に効く。見ているタイミングが違うので両方貼る
• レベル名は検証されるが、バージョンは検証されない。 enforce: strict は拒否されるのに enforce-version: v1.99 は受理される
• enforce を貼っても既存 Pod は死なない。次の作り直しで死ぬ。 rollout restart は成功を返し、kubectl get deploy は READY 2/2 に見え、異常は UP-TO-DATE 0 の 1 箇所だけ。本当の状態は describe rs の FailedCreate に出る
• これは第2巻第16回の quota 超過と同じ診断構造。 「Deployment は正常に見えるのに Pod が増えない」ときは ReplicaSet の Events を見る
• クラスタ全体を棚卸しすると二極化が見える。 ArgoCD / cert-manager / Traefik / Gatekeeper は Restricted 適合済み、CNI / CSI / MetalLB / 監視 / Velero は Baseline すら満たせない
• ラベルは貼り忘れる。 塞ぐのは --admission-control-config-file の AdmissionConfiguration。第5回の extraArgs / extraVolumes に 1 フラグ + 1 extraVolume を足すだけ
• HA では 3 台すべての Control Plane に配らないと「たまに効く」状態になる。 HAProxy は roundrobin なので、同じ kubectl apply が成功したり失敗したりする。しかも kubectl get では何も見えない
• 既定を厳しくする前に、特権が要る namespace へ明示ラベルを貼る。 exemptions に並べるより、kubectl get ns --show-labels で読める形のほうが後任者に届く
• fanclub は Helm と ArgoCD の二重管理。 backend / frontend の正本は Git（selfHeal で巻き戻る）、db / logcollector / CronJob の正本は Helm chart。手を入れる前に「このリソースの正本はどこか」を確認する
• Restricted 化には実測でしか分からない追加が要る。 frontend は /var/run の emptyDir（NET_BIND_SERVICE は不要）、db は fsGroup: 999、backend は initContainer 2 本への securityContext
• PSS では latest タグもレジストリも必須ラベルも表現できない。 そこは VAP（CEL）か Gatekeeper（Rego）で足す
• 素朴な CEL 式は取りこぼす。 タグ省略（nginx）と initContainers を見落とし、contains(':') だけだとレジストリのポート番号（k8s-registry:5000）を誤検知する
• 潰した式にもまだ抜けがある。 ephemeralContainers は見ておらず、ダイジェスト指定は通る（こちらは通してよい）
• Gatekeeper は apply が通ってもポリシーが効いていないことがある。 import rego.v1 のエラーは status.byPod[].errors にしか出ない。v3.23.0 は Rego v0 記法
• Gatekeeper の既定は fail-open（failurePolicy: Ignore）。 落ちればポリシーは黙って素通りする。VAP は組込なので Fail を安心して書ける
• Gatekeeper にしかできないのは audit（既存リソースの常時棚卸し）。 記法の差は学習コストの差だが、audit の有無は機能そのものの差。これが要るかどうかが選択の分かれ目
• 一貫した順序は「まず PSS、足りない分だけ VAP、VAP で書けないものだけ Gatekeeper」

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

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

1. warn=restricted ラベルを --dry-run=server で当てると、その namespace の既存 Pod の違反が一覧できる
2. namespace に enforce=restricted を貼ると、すでに動いている違反 Pod はその場で削除される
3. enforce 適用後に rollout restart した Deployment は、kubectl get deploy の READY 列だけを見ても異常に気づけない
4. AdmissionConfiguration を 1 台の Control Plane Node に置けば、HA クラスタ全体に効く
5. Gatekeeper の ConstraintTemplate は kubectl apply が成功すれば、ポリシーが有効になったと判断してよい
6. Gatekeeper の validation.gatekeeper.sh は既定で failurePolicy: Ignore であり、Gatekeeper が停止するとポリシーは素通りする
7. object.spec.containers.all(c, !c.image.endsWith(':latest')) という CEL 式は、タグを省略した nginx も拒否できる
8. PSS の Restricted が capabilities.add に許す値は NET_BIND_SERVICE だけである
9. Restricted 準拠の PostgreSQL を新規ボリュームで起動するには、runAsUser に加えて fsGroup の指定が要る

次回予告#

第9回「Secret 管理（etcd 暗号化 / SealedSecrets / ExternalSecrets）」では、D4 の 2 つ目のコンピテンシーへ進みます。本回は「危険な Pod を作らせない」入口の話でしたが、次回はすでにクラスタの中にあるもの——etcd に平文で保存されている Secret を扱います。

base64 は暗号化ではないという前提から、保存時暗号化（Encryption at Rest）、Git に置ける SealedSecrets、外部ストア連携の ExternalSecrets まで進み、fanclub の DB パスワードを GitOps セーフな形にします。第2回で保留した kube-bench の WARN（1.2.27 / 1.2.28）も、そこで回収します。

→ 詳しくは 第9回 Secret 管理（etcd 暗号化 / SealedSecrets / ExternalSecrets）

リンク