CKS試験直前対策と暗記総まとめ【第19回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第19回、最終回です。最終回にあたります。第2回から第18回までで、CIS 準拠化からインシデント対応まで一周しました。本回は新しい技術を 1 つも入れません。 積み上げたものを棚卸しし、試験で書ける形へ翻訳し直します。

本回の中心にある事実を、最初に置きます——クラスタに残っているものと、試験で書けなければならないものは、一致しません。 残っているのに試験に出ないものがあり、試験に出るのに残っていないものがあり、そもそも一度も動かせなかったものがあります。積み上げを数えても、それは答案になりません。

第17回の中心は「防御は検知を生まない」でした。第18回は「防御は調査も妨げる」でした。本回はその 3 つ目です——到達状態は、そのままでは答案になりません。 3 回とも「積み上げたものが、そのままでは次の目的に使えない」という同じ形の反転です。

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

第18回と本回では、読者の頭の使い方が違います。 第18回は「起きている事案に対して、いま何をするか」を考える回でした。本回は「本を閉じたあと、試験当日までに何をするか」を決める回です。手を動かすのは確認と自己テストだけになります。

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

第6部 監視・ログ・ランタイムセキュリティ（D6）
    第15回: Falco ランタイム検知（D6）
    第16回: 監査ログ設計・分析 + 攻撃フェーズ特定（D6）
    第17回: 多面的脅威検知の体系 + コンテナ不変性 + アラート連携（D6）

第7部 インシデント対応・総括
    第18回: セキュリティインシデント対応 DAIR 実戦
  ★ 第19回: CKS 試験直前対策 + 第3巻完走宣言 + Kubestronaut への道  ← 今ここ（最終回）

この回のゴール#

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

• 自分のクラスタを 4 つの箱に棚卸しし、試験対策の時間をどこに使うかを決められる
• 参照できない 10 ツールのコマンドを、ドキュメントを開かずに打てる
• base とタスクごとの SSH ホストという CKS 固有の作法に沿って動ける
• 120 分の中で、配点（D4・D5・D6 で 60%）に沿った 3 パスの進め方を実行できる
• Kubestronaut 5 冠までの残作業と、CARE による維持コストの下がり方を数字で説明できる

手元の kubectl は、試験と同じ世代になっている#

版行に 1 つ、教材になる組み合わせがあります。本ラボの API Server は v1.36.3、k8s-ops の kubectl は v1.35.6 で、1 マイナーずれています。第5回のパッチアップグレードで API Server 側だけが進み、作業端末の kubectl は第2巻で入れたままだからです。

ラボに残っているものと、試験で問われるもの —— 4 つの箱#

第3巻はここまで 18 回、防御を積み上げてきました。しかし、いまクラスタに残っているものを数えても、それは試験の答案にはなりません。残っているのに試験に出ないものがあり、試験に出るのに残っていないものがあり、そもそも一度も動かせなかったものがあるからです。

本回では、18 回分の到達を次の 4 つの箱に仕分けます。以降の節は、この 4 つを順に処理していく作業になります。

図にすると、B と C が同じ外枠の中で分かれていることが見えます。どちらも「残っていないのに試験に出る」ですが、B は手順が本文に残っており、C は残っていません。この違いが、対策の立て方を分けます。

B と C を分ける理由#

この 2 つは「試験に出るのにクラスタに無い」という点では同じですが、補完の方法がまったく違います。 C は「やれなかった」ので、外部環境で手を動かすしかありません。B は「やった上で外した」ので、手順は本文に残っており、読者は各回に戻れば読み返せます。同じ表に混ぜると、対策の立て方を間違えます。

箱を分ける根拠は、すべて実機の事実にある#

1. 試験に出るのに、ラボに残っていない機構が 4 つあります。 次節のやってみよう①で、4 つとも空であることを実測します
2. Gatekeeper の webhook だけは残り続けています。 ValidatingWebhookConfiguration は 5 件あり、そのうち 1 件が gatekeeper-validating-webhook-configuration（webhook 2 件）です。しかし Constraint は 0 本で、何も止めていません
3. ラボにあって試験に無いものが多くあります。 Helm リリースは 13 本残っていますが、helm.sh/docs は CKS では参照すらできません。helm コマンドそのものが出題範囲外です
4. 試験にあってラボに無いものもあります。 試験ホストには alias k=kubectl と Bash 補完、yq がプリインストールされていますが、本ラボの k8s-ops には k エイリアスも yq も入っていません。逆に、ラボにあって試験に無い jq を本文で多用してきました（第4回で明記）

やってみよう①：クラスタの棚卸し —— 箱 A と箱 B を実機で確定させる#

自分のクラスタに何が残り、何が残っていないかを実測します。本演習で使うのは読み取りコマンドだけです。 apply も delete も label も打ちません——第3巻はここで完結するため、状態を変えずに終えます。

ステップ1：箱 A —— 残っている防御を数える#

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

$ kubectl get networkpolicy -n fanclub --no-headers | wc -l
$ kubectl get ciliumnetworkpolicy -n fanclub --no-headers
$ kubectl get ns fanclub -o jsonpath='{.metadata.labels}'
$ kubectl get sa,role,rolebinding -n fanclub --no-headers
$ kubectl get sealedsecret -n fanclub

実行結果：

7
fanclub-backend-l7   5d14h   True
{"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/enforce":"restricted","pod-security.kubernetes.io/enforce-version":"latest","pod-security.kubernetes.io/warn":"restricted","pod-security.kubernetes.io/warn-version":"latest"}
serviceaccount/default           8d
serviceaccount/fanclub-backend   8d
role.rbac.authorization.k8s.io/fanclub-backend-reader   2026-07-25T18:03:05Z
rolebinding.rbac.authorization.k8s.io/fanclub-backend-reader-binding   Role/fanclub-backend-reader   8d
NAME                STATUS   SYNCED   AGE
fanclub-db-secret            True     6d17h

回ごとの成果を、確認コマンドと期待値の形で並べます。この表は「自分のクラスタが第3巻の到達状態にあるか」の点検表としてそのまま使えます。

第17回で数えた「本ラボの穴 3 つ」は、いま 2 つに減っています。第17回は「Users 面が空（第16回で監査ログを撤去した）/ Gatekeeper は Constraint 0 本 / 署名検証は第14回で撤去」と書きましたが、第18回の Postmortem で監査ログを常設したので Users 面は塞がりました。第17回の記述が誤っていたのではなく、その後の作業で 1 つ埋まったという経過です。

ステップ2：箱 B —— 残っていない機構を数える#

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

$ kubectl get constrainttemplates
$ kubectl get validatingadmissionpolicy
$ kubectl get runtimeclass
$ kubectl get pod -n kube-system -l component=kube-apiserver -o jsonpath='{.items[0].spec.containers[0].command}' | tr ',' '\n' | grep -E 'admission-control-config-file|enable-admission-plugins'

実行結果：

No resources found
No resources found
No resources found
"--enable-admission-plugins=NodeRestriction"

4 つとも空です。 Gatekeeper の Constraint と ValidatingAdmissionPolicy（第8回）、RuntimeClass（第10回）、ImagePolicyWebhook（第14回）は、いずれも演習で入れたあと、同じ回のうちにクラスタから消えています。

ただし、消えた理由は 4 つとも同じではありません。 ここを一括りにすると、第3巻が積み上げてきた設計判断が失われます。

ステップ3：それでも webhook は残っている#

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

$ kubectl get validatingwebhookconfiguration --no-headers
$ kubectl get validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -o jsonpath='{range .webhooks[*]}{.name}{"\n"}{end}'

実行結果：

cert-manager-webhook                          1     8d
gatekeeper-validating-webhook-configuration   2     5d14h
kube-prometheus-stack-admission               2     8d
longhorn-webhook-validator                    1     8d
metallb-webhook-configuration                 6     8d
validation.gatekeeper.sh
check-ignore-label.gatekeeper.sh

Gatekeeper 本体と webhook 2 件は残っています。 しかし判断させるルール（Constraint）が 0 本なので、何も止めません。

ただし、この 3 点は同じ形の答えを返しません。 本ラボで打つと、返り方が 2 種類に分かれます。

constraints は ConstraintTemplate が生やす CRD です。テンプレートが 0 本なら、そもそも型が存在しません。エラーが返ることは失敗ではなく、「1 本も定義されていない」という答えそのものです。試験で「ポリシーが効いているか調べよ」と言われたとき、このエラーを見て手が止まるのが、最もありがちな時間の使い方になります。

ステップ4：箱 D —— 試験に出ないものを確認しておく#

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

$ helm list -A --no-headers | wc -l

実行結果：

13

13 リリースのうち CKS の出題対象は Cilium / Falco / Gatekeeper / SealedSecrets の 4 つだけです。残る 9 つ（fanclub 自身 / Traefik / cert-manager / ArgoCD / kube-prometheus-stack / Loki / Fluent Bit / Longhorn / MetalLB）は試験に出ません。helm コマンドそのものも CKS の出題範囲外です（第15回・第17回で明記）。

この 4 対 9 という比が、箱 D の実感になります。18 回かけて育てたものの大半は、試験には出ません。 三部作の題材として最後まで動かし続けた fanclub ですら、CKS の設問に現れることはありません。それでも積み上げてきたのは、試験に受かることと、クラスタを守れることが同じではないからです。

CKS 試験の最終確認と 6 ドメインの配点#

ここからは箱の話をいったん離れ、試験そのものの事実を確定させます。以下はすべて 2026-08-03 に公式ページから取得した値です。

6 ドメインの配点#

D4 + D5 + D6 で 60% です。この比率が、後述する時間配分と暗記の重みづけの根拠になります。

ラボと試験のバージョン差#

ラボは v1.36.3、試験は v1.35 で、1 マイナー + パッチの差があります。Linux Foundation は「Kubernetes のリリースから概ね 4〜8 週間で試験環境を最新マイナーへ整合させる」としているので、受験前に公式ページで試験バージョンを確認してください。第8回で確認したとおり、pod-security.kubernetes.io/enforce-version: latest の解決先はクラスタのバージョンに引きずられます——ラボで latest と書くと v1.36 の定義、試験環境なら v1.35 の定義になります。

なお cncf/curriculum の CKS カリキュラム文書は CKS_Curriculum v1.34.pdf が最新です（CKA / CKAD は v1.35）。これはドメイン定義の版であって、試験環境のバージョンとは別物です。混同しないでください。

試験環境の作法 —— base とタスクごとの SSH ホスト#

CKA / CKAD 経験者が最も戸惑うのがここです。CKS は「タスクごとに指定される SSH ホスト上で作業する」方式で、context を切り替えて回る CKA / CKAD の作法とは違います。以下は Important Instructions: CKS に明記されている作法です。

本ラボの作法は、試験とほぼ正反対です。 本書ではここまで k8s-ops から各ノードへ多段 SSH して作業してきましたが、試験ではそれができません。逆に、試験ホストには k エイリアスと yq がありますが、k8s-ops にはどちらも入っていません。手が覚えた動きを、そのまま持ち込めないということです。

開始直後に打つのは 1 行だけ#

暗記カード（試験ホスト上）：

export do="--dry-run=client -o yaml"

• alias k=kubectl は打つ必要がありません。 設定済みです。本書ラボの k8s-ops には入っていないので、そこは差分になります
• export do= は第9回で導入し、第6回・第8回・第14回・第15回で繰り返し推奨した時短です。全ドメインで効きます
• yq が使えるので、既存マニフェストへのフィールド追加はエディタを開かずに済ませられます（第4回で提示済み）
• kubectl config use-context は打ちません。 CKS はタスクごとに SSH ホストが指定される方式で、公式の指示にも context 切り替えの記載はありません

最後の 1 点は、本回の主題そのものの実例です。CKA で身についた手が、CKS の答案に無意識に混ざります。 「試験の最初にやること」として体が覚えている動作ほど、疑われないまま持ち込まれます。

ラボと試験の道具の差#

参照可能 8 件の使いこなし#

第5回で立てた判断基準を、そのまま持ち込みます。

この 8 件には第1回で一度触れ、第12回以降は各回の文脈で必要な行だけを再掲してきました。全量の正本は下の表です。 各回の再掲と食い違って見えたときは、こちらを取ってください。

加えて、ターミナル上の試験指示・ディストリビューション同梱ドキュメント（/usr/share 配下 = man）・ディストリビューションのパッケージ（既定に無ければ導入も可）が許可されています。検索については、kubernetes.io/docs/ の検索機能は使用可ですが、外部検索結果を開くのは不可です。

CKS で参照できないもの（CKA / CKAD との差）#

本ラボは Gateway API と cert-manager で HTTPS を出していますが、gateway-api.sigs.k8s.io は CKS では参照できません。試験で TLS を問われたら、標準 Ingress の spec.tls + kubernetes.io/tls Secret で解答します。kubectl create secret tls は最頻出です（第3回）。

サブパス限定の 3 件は URL ごと覚えます（第13回で確定）。docs.cilium.io/en/stable は許可されていても、docs.cilium.io のトップから辿ることはできません。同様に bom は cli-reference/ 配下、ingress-nginx は user-guide/nginx-configuration/ 配下だけです。

時間配分 —— 120 分の 3 パス戦略#

1 パス目で飛ばす判断基準#

• クラスタを再起動させる操作を含む問題（apiserver / kubelet の再起動待ちが入る）は 2 パス目へ回す
• ノードを跨ぐ問題（base からの SSH 先が複数）は移動コストが高いので後回しにする
• 3 分打っても手が止まる問題は、その時点の知識では解けない。次へ行く

全問共通の鉄則（本巻で確立したもの）#

1. static Pod は編集前に必ずバックアップします（第2回で確立。/etc/kubernetes/manifests/ の外へ置きます）
2. ファイル参照フラグは 3 点セットです（フラグ + volumeMounts + volumes）。第2回で原則を立て、第5回・第9回・第14回・第16回・第18回で 5 回組んだ型です（ログ出力先だけは readOnly を付けません——第16回・第18回がその例です）
3. API が落ちている間の真実は crictl ps だけです（第2回・第5回）
4. HA では全 Control Plane に同じ設定を入れます（第9回・第14回・第16回・第18回）。1 台だけだと LB の振り分け次第で結果が変わります
5. --dry-run=server は API に届き、--dry-run=client は届きません（第8回）。効くかどうかを試すなら server です
6. 成功表示は成功を意味しません（第8回・第9回・第10回・第15回・第17回・第18回で 6 回出た型）。apply が通っても status を見ます。helm upgrade が失敗しても rollout status は成功と言い（第15回）、送信が 200 でも受け皿が null なら誰にも届きません（第17回）

3 パス目の検証コマンド集#

暗記必須コマンド総まとめ① —— 参照できない 10 ツール#

第2回から第18回までの「暗記必須コマンド」は、合わせて 267 行あります。全部を並べても読み切れません。ここでは 3 層に分けて渡します。

整理の単位は回ではなくツールです。回単位で覚えると、試験中に「これは何回目でやったか」を思い出す手順が挟まります。配点は掲載順の根拠としてのみ使います。

当日カード（20 行）#

暗記カード（試験開始から終了まで、実際に手が打つもの）：

export do="--dry-run=client -o yaml"
kubectl auth can-i <verb> <res> --as=system:serviceaccount:<ns>:<sa> -n <ns>
kubectl create secret tls <name> --cert=tls.crt --key=tls.key -n <ns>
kubectl label ns <ns> pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest
kubectl explain pod.spec.securityContext --recursive
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak
crictl ps | grep kube-apiserver
kube-bench run --targets master
trivy image --severity HIGH,CRITICAL --exit-code 1 <image>
cosign generate-key-pair
cosign sign --key cosign.key <img>@sha256:<digest>
cosign verify --key cosign.pub <img>
bom generate --image <img> --output sbom.json --format json
kubesec scan <file>
kube-linter lint <path>
grep Seccomp /proc/1/status
ausearch --input-logs -m AVC -ts recent
kubectl logs -n <ns> -l <label> -c falco
kubectl debug <pod> -it --image=<img> --target=<container> --profile=restricted

この 20 行は、各回の本文が「試験で打つのはこの形だけ」と明示した行を集約したものです。第14回「試験で打つのは、次の 3 行だけです」、第15回「試験で打つのは、次の形だけです」、第12回「kubectl explain を引く手を覚える」——といった記述が出どころです。

厳選版 —— 参照できない 10 ツール（各 4 行 × 10 = 40 行）#

掲載順は配点順ではなく、「引けないから覚えるしかない」度合いの順です。各ツールをちょうど 4 行に絞ります。網羅ではなく、試験で手が動く最小セットにするためです。4 行に収まらないツールについては、その 4 行を選ぶ判断そのものが中身になります。

1. Trivy（trivy.dev は 8 件に入っていない）#

trivy image --severity HIGH,CRITICAL --exit-code 1 <image>
trivy fs --severity HIGH,CRITICAL <dir>
trivy config <dir>
trivy k8s --report summary

よくある取り違え: --severity HIGH, CRITICAL とスペースを入れる（入れません）。--exit-code 1 を付けずに「ゲートした」と思う（付けないと落ちません）。CI で使うのは trivy fs であって rootfs ではありません。--ignore-unfixed は「無視」ではなく「後回し」です。

2. Cosign（sigstore.dev も github.com/sigstore/cosign も不可）#

cosign generate-key-pair
cosign sign --key cosign.key <img>@sha256:<digest>
cosign verify --key cosign.pub <img>
cosign tree <img>

よくある取り違え: sign をタグ指定でやる（ダイジェスト指定が本来）。cosign attach sbom は DEPRECATED で、SBOM の添付は cosign attest --predicate <sbom> --type spdxjson --key cosign.key <img> です。

3. OPA Gatekeeper（open-policy-agent.github.io は許可 8 サイトに含まれない）#

apiVersion: templates.gatekeeper.sh/v1
spec.crd.spec.names.kind: <ConstraintKind>
apiVersion: constraints.gatekeeper.sh/v1beta1
kubectl get <ConstraintKind> <name> -o jsonpath='{.status.byPod[0].enforced}'

よくある取り違え: Rego v1 記法で書く（import rego.v1 は bad import で ingest エラーになり、apply は通るのに効きません）。Constraint の kind: をテンプレート名にしてしまう（テンプレートが生やした CRD 名を書きます）。違反の確認は {.status.violations} です。

4. gVisor / containerd 2.x（gvisor.dev も containerd.io も含まれない）#

head -1 /etc/containerd/config.toml
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runsc]
runtime_type = 'io.containerd.runsc.v1'
containerd config dump | grep -A 6 runtimes.runsc

よくある取り違え: RuntimeClass（node.k8s.io/v1 / handler: runsc）自体は kubernetes.io/docs で引けますが、containerd 2.x（version = 3）のテーブル名はどこにも載っていません。版を head -1 で確認してから書きます。サンドボックスで動いているかの判定は uname -r が 4.19.0-gvisor を返すかどうかです。

5. AppArmor（不可。man は可）#

cat /sys/kernel/security/lsm
apparmor_parser -q /etc/apparmor.d/<profile>
aa-status
cat /sys/kernel/security/apparmor/profiles

よくある取り違え: 記法（securityContext.appArmorProfile）は kubernetes.io/docs で引けるので、暗記対象はロード側の 4 行です。localhostProfile に書くのはファイルパスではなくプロファイル名——seccomp の Localhost（/var/lib/kubelet/seccomp/ からの相対パス）とは非対称です。

6. SELinux（許可リスト外。man のみ）#

getenforce
semanage fcontext -a -t container_file_t '<path>(/.*)?'
restorecon -Rv <path>
ausearch --input-logs -m AVC -ts recent

よくある取り違え: chcon -t container_file_t はその場しのぎで、restorecon やラベル再設定で戻ります。恒久化は semanage fcontext + restorecon の 2 段です。拒否が複数隠れているときは semodule -DB で dontaudit を外し、調査が終わったら semodule -B で必ず戻します。真偽値の恒久化は setsebool -P、ラベル確認は ls -Z / ps -eZ です。

7. kube-bench（許可 8 件のどこにも載っていない）#

export KUBECONFIG=/etc/kubernetes/admin.conf
kube-bench run --targets master
kube-bench run --targets node --check 1.2.15 --include-test-output
kube-bench run --benchmark cis-1.12 --group 1.2

よくある取り違え: root で打つと KUBECONFIG が無く、判定がごっそり WARN になります。1 行目を忘れないでください。--targets には master / node / etcd / controlplane / policies が指定できます。

8. Kubesec / KubeLinter（kubesec.io も docs.kubelinter.io も不可）#

kubesec scan <file>
kubesec scan <file> --exit-code 2
kube-linter lint <path>
kube-linter checks list

よくある取り違え: 減点幅を覚えていないと、どこから直すかを決められません。-30（privileged / SYS_ADMIN）、-9（host 系・docker.sock・/proc）、-7（allowPrivilegeEscalation: true）の順です。KubeLinter の設定は .kube-linter.yaml の checks.include / exclude / addAllBuiltIn: true です。

9. kubeseal / SealedSecrets（許可 8 サイトに含まれない）#

kubeseal --fetch-cert
kubectl create secret generic <name> -n <ns> --from-literal=<key>=<value> --dry-run=client -o yaml | kubeseal --format yaml
kubeseal --cert <cert> --format yaml --scope namespace-wide
kubeseal --re-encrypt --format yaml

よくある取り違え: --format yaml を忘れる（既定は json です）。--scope は strict（既定）/ namespace-wide / cluster-wide の 3 値で、strict は名前と Namespace の両方に縛られます。復旧は --recovery-unseal --recovery-private-key、コントローラに管理させるアノテーションは sealedsecrets.bitnami.com/managed=true です。

10. ホスト OS 系（第7回の 25 行のうち、参照できるのは最後の 1 行だけ）#

systemctl mask <unit>
systemctl list-unit-files --type=service --state=enabled
ss -ltnup
firewall-cmd --permanent --remove-service=<svc> && firewall-cmd --reload

よくある取り違え: disable では依存経由の起動が止まりません。止めるなら mask です。--permanent を付けたら --reload までがワンセットです。SSH は sshd -T（実効値）と sshd -t（構文チェック）の使い分け、sudo は visudo -c -f <file> → install -m 0440 -o root -g root → visudo -c の順、権限の確認は sudo -l -U <user> です。

全量版 267 行の索引#

残る全量は、各回へ戻って回収します。「どの回に何があるか」を思い出せる索引として使ってください。

暗記必須コマンド総まとめ② —— 参照できるのに、開かずに打てると差がつくもの#

1 問 5〜12 分の試験で、書式を確かめにドキュメントを開くたびに 1〜2 分が消えます。ここに挙げるのは「載っていないから覚える」ではなく、開かずに打てるようにしておくと差がつく項目です（第4回が立てた区分を全 18 回へ広げます）。12 領域から 20 行を選びました。

暗記しないものを決める —— ラボ固有の事情の切り分け（箱 D）#

ここからは箱 D の処理です。第13回から第18回までが各回で書いてきた「ラボ固有」の表を、1 つに統合します。何を覚えないかを決めるのは、覚えることを決めるのと同じくらい試験対策になります。

やってみよう②：CKS 形式の模擬問題 6 問#

ここまでで、どこに時間を使うかは決まりました。次は書けるかどうかです。CKS と同じパフォーマンスベース形式で、第2回から第18回までの範囲から 6 問出します。6 問・合計 52 分です。

• 各問に想定時間があります（CKS は 1 問 5〜12 分が目安）。時計を見ながら解いてください
• クラスタの状態を変えません。 各問の「実行方針」に従ってください
• 解答は試験環境で通る形で書きます。ラボ固有のフラグを解答例に混ぜません——前節で「覚えなくてよい」と切り分けた側のものです

各問の実行方針#

Q5 のスキャンで、本回の主題がもう一度出る#

本ラボで素の trivy image を打つと、次のようになります。

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

$ time trivy image --severity HIGH,CRITICAL --exit-code 1 k8s-registry:5000/fanclub-backend:0.4.1

実行結果：

INFO	[vulndb] Need to update DB
INFO	[vulndb] Downloading vulnerability DB...
INFO	[vulndb] Downloading artifact...	repo="mirror.gcr.io/aquasec/trivy-db:2"
FATAL	Fatal error	run error: init error: DB error: failed to download vulnerability DB: OCI artifact error: failed to download vulnerability DB: failed to download artifact from mirror.gcr.io/aquasec/trivy-db:2: OCI repository error: 1 error occurred:
	* Get "https://mirror.gcr.io/v2/": Forbidden

real	0m0.052s

real 0m0.052s——スキャンが始まる前に落ちています。 mirror.gcr.io が alma-proxy の whitelist に無いため、脆弱性 DB を更新できず、初期化の時点で FATAL になります。「Forbidden なので結果が空になる」のではありません。--skip-db-update を足すと、キャッシュ済みの DB で完走します。

$ cat ~/.cache/trivy/db/metadata.json

"DownloadedAt":"2026-08-07T04:55:39Z","NextUpdate":"2026-08-08T01:59:50Z"

出題（6 問・合計 52 分）#

箱 B からの出題は Q4（VAP）の 1 問だけです。残りは箱 A（Q3 のみ A + C）で、実機に残っているものを題材にしています。箱 B の残り 3 つ（Gatekeeper / RuntimeClass / ImagePolicyWebhook）は、時間を測らない自己テストとして次節で扱います。

Q1 の解答例（D1・6 分）#

土台になる default-deny です（全量）。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: <ns>
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

DNS だけを開けます（全量）。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: <ns>
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

メタデータ API への egress は、この 2 本だけで遮断されています。 default-deny の下では、明示的に許可したもの以外は通らないからです。「遮断したままであること」を YAML で示すとは、0.0.0.0/0 を許可するポリシーが存在しないことを示すのと同じです。もし外部通信を開ける必要があるなら、次の形で穴を空けます（全量）。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-external-except-metadata
  namespace: <ns>
spec:
  podSelector:
    matchLabels:
      app: <app>
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

よくある減点: egress default-deny を敷いて DNS を開け忘れる（名前解決が壊れ、以降の設問すべてに影響します）。from / to の AND / OR を取り違える。効いているかは kubectl get netpol -o yaml でしか判別できません——describe の整形出力では AND / OR が読み取れません（第3回）。

Q2 の解答例（D2・8 分）#

まず読めないことを検証します。

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

$ kubectl auth can-i get secrets --as=system:serviceaccount:fanclub:fanclub-backend -n fanclub
$ kubectl auth can-i list secrets --as=system:serviceaccount:fanclub:fanclub-backend -n fanclub

実行結果：

no
no

次に Pod 単位でトークンのマウントを止めます（全量）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <name>
  namespace: <ns>
spec:
  replicas: 3
  selector:
    matchLabels:
      app: <name>
  template:
    metadata:
      labels:
        app: <name>
    spec:
      serviceAccountName: <sa>
      automountServiceAccountToken: false
      containers:
      - name: app
        image: <image>
        ports:
        - containerPort: 8080

受理されることの確認（状態は変えません）：

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

$ kubectl apply -f deployment.yaml --dry-run=server

実行結果：

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "app" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "app" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "app" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "app" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/<name> created (server dry run)

設問には関係のない Warning が 1 つ出ます。 この Deployment はトークンのマウントを止めることだけを書いていて securityContext を持たないので、第8回で fanclub に敷いた PSA restricted が 4 項目を指摘してきます。それでも created (server dry run) は返ります——enforce は Pod の作成時に効くもので、Deployment の受理そのものは止めないためです。

よくある減点: --as と --serviceaccount の書式を取り違える（--as はコロン 3 個、kubectl create 系の --serviceaccount=<ns>:<sa> はコロン 1 個）。SA 単位で patch して、既存 Pod に効いていないのに効いたと誤認する——マウントは Pod 作成時に決まるので、作り直すまで変わりません。

Q3 の解答例（D3・8 分）#

seccomp と capabilities を適用した Pod です（全量）。

apiVersion: v1
kind: Pod
metadata:
  name: hardened
  namespace: <ns>
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: <image>
    securityContext:
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

効いていることの確認です。

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

$ kubectl exec -n fanclub <pod> -c backend -- grep Seccomp /proc/1/status
$ kubectl exec -n fanclub <pod> -c backend -- grep CapEff /proc/1/status

実行結果：

Seccomp:	2
Seccomp_filters:	1
CapEff:	0000000000000000

Seccomp: 2 が filter mode、CapEff がすべて 0 なら capability は 1 つも残っていません。あわせて、AppArmor の記法は次のとおりです。

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

このクラスタでは適用できません。 AlmaLinux のカーネルは LSM に AppArmor を持たず、cat /sys/kernel/security/lsm に apparmor が現れないためです。指定した Pod は phase: Failed・STATUS 列 AppArmor で拒否されます（第6回で実測）。

よくある減点: privileged: true があると seccomp が無視されることを見落とす。効果確認を grep Seccomp /proc/1/status でやらず、マニフェストの目視で済ませる。旧アノテーション記法（container.apparmor.security.beta.kubernetes.io/<container>）を新規に書く——新規は新フィールド記法です。

Q4 の解答例（D4・10 分）#

ポリシー本体です（全量）。

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 を使わないこと"

適用先を決める Binding です（全量）。

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: <ns>

受理されることの確認（状態は変えません）：

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

$ kubectl apply -f vap.yaml -f vap-binding.yaml --dry-run=server

よくある減点: validationActions: ["Deny"] を書き忘れる（作っても止まりません）。initContainers を見ていない。タグ省略を latest として扱えていない。型チェックの結果は kubectl get validatingadmissionpolicy <name> -o jsonpath='{.status.typeChecking}' で読めます。

機構の選び方も 1 行で思い出しておきます。第8回の結論は「まず PSS、足りない制約だけ Gatekeeper / CEL」でした。latest タグの禁止は PSS の守備範囲外なので、VAP か Gatekeeper のどちらかになります。同じ要件を Gatekeeper で書く練習は、次節の自己テストで行います。

Q5 の解答例（D5・10 分）#

暗記カード（試験環境で通る形）：

trivy image --severity HIGH,CRITICAL --exit-code 1 <image>
bom generate --image <image> --output sbom.json --format json
bom document outline sbom.json
cosign generate-key-pair
cosign sign --key cosign.key <image>@sha256:<digest>
cosign verify --key cosign.pub <image>

ダイジェストは、署名する前に解決しておきます。

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

$ kubectl get pod -n fanclub -l app=fanclub-backend -o jsonpath='{.items[0].status.containerStatuses[0].imageID}'

実行結果：

k8s-registry:5000/fanclub-backend@sha256:b8113a77a17d7c7ad5ac794cce2edef9b7fa99c474154e7573c29b191529b016

よくある減点: --severity HIGH, CRITICAL とスペースを入れる。--exit-code 1 を付けずに「ゲートした」と思う。cosign sign をタグ指定でやる（ダイジェスト指定が本来です）。cosign attach sbom を使う（DEPRECATED なので cosign attest です）。

Q6 の解答例（D6・10 分）#

Audit Policy です（全量）。

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach", "pods/portforward"]
  - level: None

kube-apiserver へ渡すフラグです（全量）。

    - --audit-policy-file=/etc/kubernetes/audit/audit-policy-exec.yaml
    - --audit-log-path=/var/log/kubernetes/audit/audit.log
    - --audit-log-maxage=30
    - --audit-log-maxbackup=3
    - --audit-log-maxsize=100

3 点セットの残り 2 つ、volumeMounts と volumes です（全量）。

    volumeMounts:
    - mountPath: /etc/kubernetes/audit
      name: audit-policy
      readOnly: true
    - mountPath: /var/log/kubernetes/audit
      name: audit-log
      readOnly: false
  volumes:
  - hostPath:
      path: /etc/kubernetes/audit
      type: DirectoryOrCreate
    name: audit-policy
  - hostPath:
      path: /var/log/kubernetes/audit
      type: DirectoryOrCreate
    name: audit-log

本ラボでは第18回で 3 台の Control Plane に常設済みです。読み取りで答え合わせができます。

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

# grep audit /etc/kubernetes/manifests/kube-apiserver.yaml
# cat /etc/kubernetes/audit/audit-policy-exec.yaml

よくある減点: - level: None を最後に置かない（全部記録されて重くなります）。3 点セットのうち volumes を忘れて apiserver が起動しない。ログ出力先を readOnly でマウントする。記録側の絞り込みで verb を create だと思い込む——kubectl exec の verb は get で、絞り込みは objectRef.subresource です（第18回）。

やってみよう③：書けるかを測る —— 箱 B の弱点リスト#

3 本目は、箱 B（やった上で撤去した 4 機構）を対象にした自己テストです。なぜ箱 B かというと、ここが最も抜けやすいからです。

• 箱 A は実機で読み返せます（やってみよう① でやりました）
• 箱 C は外部環境でやるしかありません（次節）
• 箱 B だけが、手順は本に残っているのにクラスタには無い——「読めば思い出せるが、思い出せるかどうかを確かめていない」状態にあります

自己テストの手順#

1. 各項目について、ドキュメントも本書も開かずに YAML / コマンドを書きます（紙でもエディタでもかまいません）
2. 書き終えてから該当回を開いて答え合わせをします
3. 書けなかった項目を弱点リストに残します
4. Killer.sh の 1 回目を使う前に弱点リストを潰します。模擬試験は 2 回分しかないので、潰さずに使うと 1 回分が「知らないことの確認」で終わります

自己テスト項目（箱 B・4 機構）#

1 と 2 は続けて出してください。 やってみよう② の Q4 で書いた VAP と同じ制約を、今度は ConstraintTemplate + Constraint で書きます。同じ要件を 2 つの機構で書き分けると、第8回の使い分け（まず PSS、足りない制約だけ Gatekeeper / CEL）が手で思い出せます。Rego v0 のテンプレートをゼロから書くと単独で 8〜10 分かかるため、時間を測らない自己テストとしてここに置いています。

Gatekeeper でありがちな取り違えは 2 つです。Rego v1 記法で書くと、import rego.v1 が bad import で ingest エラーになり——apply は通るのに効きません。もう 1 つは、Constraint の kind: をテンプレート名にしてしまうことです。書くのは、テンプレートが生やした CRD 名のほうです。

弱点リストのテンプレート#

ラボで手を動かせなかった 4 領域と Killer.sh での補完計画（箱 C）#

ここに挙げる 4 つは、本書ラボでは一度も動かせませんでした。理由は環境の構造にあり、手順を間違えたからではありません。試験環境では動くので、Killer.sh（Ubuntu ベース）で補完します。

加えて、記法だけ復習しておく 2 つがあります。

Killer.sh の使い方#

• 試験登録には模擬試験 2 回分・各 36 時間が付きます（2026-08-03 公式確認）。外部リンク: https://killer.sh/
• 1 回目を使う前に、前節の弱点リストを潰します。 潰さずに使うと、1 回分が「知らないことの確認」で終わります
• 1 回目で AppArmor を実機で通します。 Ubuntu なので apparmor_parser が動きます。第6回で「非対応ノードでの拒否挙動」までは確認済みなので、残るは適用の 1 手だけです
• 2 回目は本番 1 週間前に、時間配分の練習として使います

なお、Killer.sh の 1 セッションは 17 問です。これは模擬試験の設問数であって、試験本体の値ではありません。 試験本体は 15〜20 タスクで、数字が近いぶん混同しやすいところです。本番のほうが幅があると覚えておいてください。

第3巻完走宣言 —— fanclub-api のセキュリティ進化#

第2巻末の時点で、fanclub-api は「動くクラスタの上で動くアプリ」でした。18 回でそれがどう変わったかを、実機で確認できた状態とあわせて 1 表にします。

図で見ると、帯から落ちているものが 3 か所あります。第8回は PSS が帯に残り Constraint と VAP だけが落ち、第14回は SBOM と署名が残り ImagePolicyWebhook だけが落ち、第10回は gVisor が丸ごと落ちています。落ちた部分がそのまま、本回の箱 B です。

到達点#

第2巻末の「動くクラスタ」から、CIS 準拠 → ネットワーク最小化 → 権限最小化 → カーネル層の拘束 → ホストの縮小 → Admission → Secret の保存時暗号化 → 通信の暗号化と L7 → イメージの検証 → ランタイム検知 → 監査 → インシデント対応まで、18 回で 1 周しました。防御は層になっており、どの層も単独では十分ではないことを、各回で実測してきました。

同時に、外したものも数えた#

gVisor / ImagePolicyWebhook / Gatekeeper Constraint / VAP は入れて外し、mutual authentication / distroless / trivy k8s / keyless は入れないと決め、Falco（第15回）と exec 限定の監査ログ（第18回）を残しました（第15回の「入れない / 入れて外す / 残す」の 3 区分）。3 区分を立てた第15回の時点で「残す」は Falco 1 つでしたが、第18回の Postmortem で監査ログが 2 つ目として加わりました——同じ監査ログが第16回では「入れて外す」側だったことを含めて、判断は回をまたいで動きます。 足した数ではなく、判断した数が第3巻の成果です。

三部作の完走#

第1巻（CKAD・アプリ開発）、第2巻（CKA・クラスタ構築運用）、第3巻（CKS・防御と検知）で、同じ 1 つのアプリを 54 回にわたって育て切りました。同じ fanclub-api が、kind の上で動くところから、HA クラスタで暗号化され検知され監査される状態まで来ています。

Kubestronaut 5 冠ロードマップ —— CARE を含む#

5 資格の条件を並べます（2026-08-03 公式確認）。

多肢選択試験の合格点 75% は公式 FAQ の明記です（”A score of 75% or above must be earned to pass the Multiple Choice Exam.”）。結果は即時ではなく、24 時間以内にメールで届きます。 また試験中に他のアプリやブラウザウィンドウを開けません——実技試験と違い、ドキュメントを参照できません。

KCSA は第3巻とどれだけ重なるか#

KCSA は第3巻の知識が新しいうちに受けると効率がよくなります。 第17回で「6 面の脅威検知は KCSA の出題範囲とも重なる」と書いたとおりです。

CARE —— 維持コストの実際#

Linux Foundation の CARE Program には、自動更新の経路が定義されています。本シリーズに関係するのは次の 3 本です。

• 公式は “Your foundational certification may be current or non-current” としています。つまり期限切れでも復活します
• 処理は自動ですが即時ではありません（数営業日）

さらに公式は、この 3 本が連鎖することを明記しています。

“Earn or recertify CKS and up to three certifications automatically renew through CARE: KCSA, CKA, and KCNA.”（CKS → KCSA + CKA → KCNA）

CKS を 1 つ受け直すだけで、KCSA と CKA が更新され、その CKA がさらに KCNA を引き上げます。 つまり 3 資格が自動更新されます。

CKS を再認定 ──→ KCSA が自動更新
             ├→ CKA  が自動更新（2026-06-18〜）
             └→ CKA 経由で KCNA も自動更新

実際に受け直すのは CKS と CKAD の 2 つだけ

残る CKAD だけは自分で受け直す必要があります（CKAD を更新する経路は CARE にありません）。ただし CKAD の再認定は KCNA も引き上げるので、CKS と CKAD の 2 つを回していれば 5 冠は維持できます。

5 資格をすべて有効に保持した状態で CNCF に申請すると、Kubestronaut として認定されます（バッジ / ジャケット / コミュニティ参加資格）。外部リンク: https://www.cncf.io/training/kubestronaut/

残り 2 資格の進め方#

1. CKS を受けます。 第3巻完走の時点で準備は整っています。Killer.sh 2 回分を前節の計画どおりに使ってください
2. KCSA を続けて受けます。 第3巻の知識が最も新しいタイミングです（90 分・多肢選択・75%）
3. KCNA を受けます。 三部作全体でカバー済みです（90 分・多肢選択・75%）
4. Kubestronaut 5 冠達成

まとめ#

• クラスタに残っているものと、試験で書けなければならないものは一致しません。 本回の作業は、積み上げを数えることではなく 4 つの箱への棚卸しでした
• 試験に出るのに残っていない機構が 4 つあります（Gatekeeper Constraint / VAP / RuntimeClass / ImagePolicyWebhook）。すべて演習で入れて、同じ回のうちに撤去しました——ただし片付けただけのものと判断して外したものに分かれます
• webhook が残っていることは、ポリシーが効いていることを意味しません。 Gatekeeper の webhook 2 件は残っていますが Constraint は 0 本で、constraints という型自体が存在しません
• 残っているのに試験に出ないものも多くあります。 Helm リリース 13 本のうち出題対象は 4 つで、helm 自体が出題範囲外です
• 参照可否は、そのページが許可 URL のサブパスにあるかだけで決まります。 crictl は引けて、バージョンスキューは引けません
• 暗記の総量は 267 行です。 当日カード 20 行・厳選 60 行・全量は各回に戻る、という 3 層で持ちます
• 覚えないものを決めます。 プロキシ回避・OCI 経路・inotify・GitOps 経由の反映は、試験の点数を 1 点も増やしません。ただし実務では逆になります
• ラボで一度も動かせなかった領域が 4 つあります（AppArmor / Kata / Istio mTLS / Cilium mutual authentication）。Killer.sh の 1 回目を使う前に弱点リストを潰します
• CARE により、5 冠の維持で実際に受け直すのは CKAD と CKS の 2 つで足ります

第3巻は 19 回で、防御を積み、その防御が何を生み、何を生まないかを毎回測ってきました。第17回で「防御は検知を生まない」ことを、第18回で「防御は調査も妨げる」ことを、本回で「到達状態はそのままでは答案にならない」ことを確認しました。足した数ではなく、判断した数が第3巻の成果です。 gVisor と ImagePolicyWebhook を外し、mutual authentication を記法に留め、Falco を残した——その判断の記録が、いま手元にあるクラスタと、この本文です。読者はいま、CKS の受験準備が整った状態にいます。

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

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

1. CKS の試験環境は Kubernetes v1.35 で、本書ラボの v1.36.3 とは 1 マイナー + パッチの差がある
2. helm.sh/docs は CKA では参照できるが、CKS では参照できない
3. docs.cilium.io はトップページから辿って任意のページを参照できる
4. kubectl get validatingwebhookconfiguration に Gatekeeper の webhook が並んでいれば、ポリシーは効いている
5. CKS の試験ホストには alias k=kubectl と bash 補完、yq がプリインストールされている
6. CKS では、SSH 先のホストからさらに別のホストへ SSH してよい
7. bom のドキュメントは試験中に参照できないため、コマンドを暗記する必要がある
8. CKS を取得すると、CARE により CKA の有効期限が延長される
9. KCNA と KCSA は多肢選択式で、合格点は 75%・試験時間は 90 分である

おわりに#

本回で第3巻は完結です。第1回で「防御は足し算では強くならない」と書き、19 回かけてその意味を実測で埋めてきました。入れたものより、外したものと、外すと決めた理由のほうが多く残っています。 それが本巻の形です。

次にやることは 2 つだけです。1 つは、本回で作った当日カード 20 行を毎日 1 回読み返すこと。もう 1 つは、弱点リストの 4 領域を潰してから Killer.sh の 1 回目を使うことです。順番を逆にすると、模試 2 回のうち 1 回を「知らないことの確認」に使ってしまいます。

CKS に合格すると、CARE により KCSA・CKA・KCNA が同時に更新されます。残るのは KCNA と KCSA の取得だけで、どちらも多肢選択式・90 分の試験です。そこまで進むと Kubestronaut の 5 冠が揃います。 実技 3 資格の準備はここで整いました。あとは手を動かした回数がそのまま点数になります。

リンク