CKSとは何か＋学習ロードマップ【CKS第1回】

新卒インフラエンジニア向け「Kubernetes 実践教科書 ③ CKS セキュリティ・ハードニング編」（全19回）の第1回です。第3巻は三部作の最終巻にあたり、第2巻で構築した kubeadm HA クラスタを「攻撃を想定して守り、異常を検知し、対応する」段階へ引き上げます。第1回は、その入口となる地図を渡す回です。CKA（運用）と CKS（防御・検知）の境界、4C セキュリティモデルと脅威モデル、CKS 6 ドメインの全体像、受験の実務情報、そして Kubestronaut 5 冠への道筋を確認し、最後に 9 VM 環境の疎通確認と kube-bench のプレ実行で現状のセキュリティスコアのベースラインを取ります。

目次

1. 第1回のスコープ・今ここマップ
2. この回のゴール
3. 第3巻オリエンテーション ——三部作の最終巻で何が変わるか
4. CKA と CKS の境界 ——「建てる・運用する」と「守る・検知する」
5. CKS 試験の全体像 ——6 ドメイン・配点・受験要件
6. CKS 受験の実務情報 ——試験環境・参照可能ドキュメント・Killer.sh
7. 第3巻で扱う技術スタックと 9 VM 環境
8. やってみよう：9 VM 環境の疎通確認 + kube-bench プレ実行
   1. ステップ1：クラスタ全ノードの稼働確認
   2. ステップ2：fanclub-api の稼働確認
   3. ステップ3：alma-proxy の whitelist を確認する
   4. ステップ4：Control Plane Node に kube-bench を導入する
   5. ステップ5：Control Plane Node で kube-bench をプレ実行
   6. ステップ6：現状スコアをファイルに控える
9. fanclub-api セキュリティ強化の全体像（19 回プレビュー）
10. Kubestronaut 5 冠ロードマップ
11. 暗記必須コマンド（第1回）
12. まとめ
13. 理解度チェック（○×形式・全 9 問）
14. 次回予告

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

本回は第2巻完走者を読者として想定します。第1巻（CKAD・全19回）でコンテナとアプリ開発を、第2巻（CKA・全16回）で本番 kubeadm HA クラスタの構築・運用・GitOps を習得した状態が前提です。第3巻はその本番クラスタを CKS（Certified Kubernetes Security Specialist）の出題範囲に沿ってセキュアにしていきます。まずは第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）
    第10回: マルチテナンシー分離 + サンドボックス（gVisor/RuntimeClass）（D4）
    第11回: Cilium 透過暗号化 + L7 NetworkPolicy（Calico → Cilium 移行）（D4）

第5部 サプライチェーンセキュリティ（D5）
    第12回: 最小イメージ + 静的解析（Kubesec + KubeLinter）（D5）
    第13回: Trivy イメージスキャン + CI/CD パイプラインセキュリティ統合（D5）
    第14回: SBOM（bom）+ Cosign イメージ署名 + 許可レジストリ制限（D5）

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

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

この回のゴール#

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

• CKA（運用）と CKS（セキュリティ）の役割分担を自分の言葉で説明できる
• CKS の 6 ドメインと配点・受験要件（CKA 前提・67%・120 分・v1.35）を把握している
• 試験中に参照できる公式ドキュメントが 8 件のみであることと、暗記が必要なツールを区別できる
• 第3巻 19 回の全体像と Kubestronaut 5 冠への道筋を描けている
• 9 VM 環境の疎通を確認し、kube-bench を一度実行して現状スコアのベースラインを取れている

第3巻オリエンテーション ——三部作の最終巻で何が変わるか#

このシリーズは 3 部構成です。第1巻でコンテナ基礎からアプリデプロイまでを、第2巻で本番 kubeadm HA クラスタ構築・運用・GitOps を扱いました。本書・第3巻は、その「動いている本番クラスタ」を、攻撃を前提に守り、異常を検知し、インシデントに対応できる状態へ引き上げます。第1巻・第2巻が「作る・動かす・運用する」だったのに対し、第3巻は一貫して「守る・気づく・対応する」がテーマです。

第3巻 19 回は、CKS の 6 ドメインに沿って 7 つの部に分かれます。各部は「どの防御層を固めるか」という観点で並んでいます。

この並びは偶然ではありません。外側の防御層（クラスタ・ノード）を先に固め、その上でワークロード・コード・ランタイムへと内側に進む構成です。たとえば第8回の Pod Security Standards（Restricted プロファイル）は seccomp や capabilities といった OS 層の primitive を要求しますが、それらは先に第6回（カーネル層の強制アクセス制御）で学んでおきます。こうすることで前方参照が消え、後述する 4C モデルの順序（Cloud → Cluster → Container → Code）どおりに防御を積み上げられます。

第3巻の完走マイルストーンは第18〜19回です。第18回で fanclub-api への不正アクセス疑惑シナリオを通じて、Falco アラートの受信 → 監査ログでの影響範囲確認 → NetworkPolicy による隔離 → 復旧 → ポストモーテムという一連のインシデント対応フロー（DAIR）を完遂し、第19回で暗記必須コマンドと試験環境の作法を総ざらいします。この状態が「CKS 受験準備完了」かつ「CKS セキュリティスペシャリスト」の目安です。なお第3巻は追加 VM を必要とせず、第2巻完走時点の 9 VM 環境（kubeadm HA + ArgoCD + Longhorn + 監視・ログ）に、セキュリティツールを段階的に投入していきます。

CKA と CKS の境界 ——「建てる・運用する」と「守る・検知する」#

CKA と CKS は、対象とするクラスタは同じでも、問われる思考様式が異なります。CKA は「どうすれば動くか・どう直すか」を問う運用の資格でした。CKS は「攻撃されたらどうなるか・どう防ぎ、どう気づくか」を問う防御と検知の資格です。同じ NetworkPolicy や RBAC でも、CKA では「通信を成立させる・権限を与える」文脈で扱ったのに対し、CKS では「default deny で遮断したうえで最小限だけ許可する・過剰権限を削る」という防御の文脈で再設計します。

CKS の背景にあるのが「4C セキュリティモデル」です。これは Cloud / Cluster / Container / Code の 4 層を同心円で捉える考え方で、外側から Cloud（クラウド・データセンター・ネットワーク）→ Cluster（Kubernetes クラスタ）→ Container（コンテナ）→ Code（アプリケーションコード）の順に内側へ向かいます。重要なのは、外側の層が破られると内側の層だけでは守りきれないという点です。たとえばクラスタの API Server が無防備なら、コンテナ内をいくら堅牢にしても侵入を許します。そのため各層を独立して多層で固めます（多層防御）。

第3巻の各回は、この 4C のどこを固めるかで整理できます。クラスタ層（D1/D2）は第2〜5回、ノード/OS 層（D3）は第6〜7回、コンテナ/ワークロード層（D4）は第8〜11回、コード/サプライチェーン層（D5）は第12〜14回、そして全層を横断する監視・検知（D6）が第15〜17回です。第1回では概念の地図と脅威モデルを渡すまでにとどめ、具体的な防御実装は第2回（kube-bench / CIS）から始めます。

CKS 試験の全体像 ——6 ドメイン・配点・受験要件#

CKS は実技（パフォーマンスベース）試験で、6 つのドメインから出題されます。配点はドメインごとに決まっており、学習時間の配分を考えるうえで重要です。

配点の重心は後半 3 ドメインにあります。D4・D5・D6 で合計 60% を占めるため、「ワークロードの分離・暗号化」「サプライチェーン保護」「脅威検知」が学習時間の中心になります。第3巻の回数も、この 3 ドメインに対応する第8回以降に厚く配分しています。

試験のスペックは次のとおりです。

バージョンについて補足します。CKS の試験環境は執筆時点で K8s v1.35 が動いています。一方、本書ラボは第2巻完走時点の HA クラスタをそのまま流用するため v1.36.2 です（第2巻でマイナーアップグレードを実演した結果です）。差は 1 マイナーです。Linux Foundation は「K8s のリリースから概ね 4〜8 週間で試験環境を最新マイナーへ整合させる」としているため、この差は時期によって変動します。K8s はダウングレードに対応しないこともあり、ラボは v1.36 のまま進めます。セキュリティ機能（PSA・seccomp・監査ログ等）の挙動差は小さく、バージョン依存の差異がある箇所は各回で明示します。

紛らわしい点をひとつ補足します。CNCF が公開しているカリキュラム文書（出題ドメインの定義）は執筆時点で CKS_Curriculum v1.34.pdf が最新ですが、これはドメイン定義の版であって、試験環境で動く K8s のバージョンとは別物です。ドメインと配点は v1.34 版の定義が現行で、試験環境は v1.35 が動いている、という関係になります。

この 1 マイナーの差は、本回で扱う kube-bench では実質的に消えます。kube-bench は評価対象クラスタのバージョンから、対応する CIS Kubernetes Benchmark プロファイルを選びます。同梱の対応表は 1.34 が上限のため、v1.36 のラボでは「1.36 → 該当なし、1.35 → 該当なし、1.34 → cis-1.12」とマイナーを 1 つずつ下げて解決します。つまり ラボ（v1.36）でも試験環境（v1.35）でも、当たるプロファイルは同じ cis-1.12 です。ベンチマークの項目番号や判定内容は試験とラボで一致するため、本書で覚えた check ID はそのまま試験で通用します。

前提条件の CKA 合格は「合格歴」があればよく、有効期限内である必要はありません。受験前に CKA に合格していることが条件です。なお CNCF の CARE プログラムにより、2026 年 6 月 18 日以降に CKS を取得または再認定すると、前提資格である CKA の有効期限が自動的に延長され、新しい CKS の有効期限に揃えられます。Kubestronaut 5 冠を維持するうえで有利な仕組みです（条件は改訂され得るため、受験前に公式の最新情報を確認してください）。

CKS 受験の実務情報 ——試験環境・参照可能ドキュメント・Killer.sh#

CKS で最初に押さえるべき制約が「試験中に参照できる公式ドキュメントは 8 件のみ」という点です。CKA・CKAD では kubernetes.io をはじめ比較的広いドキュメント参照が許されていましたが、CKS では許可リストが厳格に絞られています。この制約を知らずに本番で「Trivy のオプションを調べよう」としても、該当サイトは開けません。許可されているのは次の 8 件です。

kubernetes.io はドメインとしては 1 つですが、許可リスト上は docs と blog が別項目として数えられ、合計 8 件になります。注意したいのは、4・6・7 はサブパスまで限定されている点です。たとえば bom は cli-reference/ 配下しか開けないため、それ以外のページを当てにした学習は本番で通用しません。

逆に、参照できない（＝暗記が必要な）代表例が Trivy・AppArmor・gVisor・OPA Gatekeeper・Cosign の各公式サイト、および github.com です。これらは出題されてもドキュメントを開けないため、コマンドと YAML を手に覚えておく必要があります。本書では各回末に「暗記必須コマンド」コーナーを設け、試験中に参照できないツールのコマンドを積み上げていきます。

CKA・CKAD 経験者が特に注意すべき差があります。helm.sh/docs は CKA・CKAD では参照できますが、CKS では参照できません。Gateway API のドキュメント（gateway-api.sigs.k8s.io）も CKA のみ許可で、CKS では開けません。前の試験の感覚で「あのページを見ればいい」と考えていると、本番で手が止まります。

なお、上記 8 件のほかに、タスクごとに提示される Quick Reference、ターミナル上の指示、ディストリビューション同梱のドキュメント（/usr/share 配下）とパッケージは利用できます。man コマンドが使える点は実戦的に大きく、man sshd_config や man firewalld.conf のように OS 側の設定はその場で調べられます。検索機能の使用は許可されていますが、外部の検索結果を利用することはできません。

試験環境は Linux デスクトップです。ここで CKA・CKAD と大きく違う点があります。CKS では、すべてのタスクをタスクごとに指定された SSH ホスト上で実施します。最初にログインする base という名前のベースシステムには作業用のツールが入っておらず、各タスクの指示に従って対象ホストへ SSH してから作業する形です。「手元でいきなり kubectl を叩く」進め方ではないため、この作法を知らないと開始直後に戸惑います。

SSH 先には、kubectl（エイリアス k と bash 補完つき）・yq・curl・wget・man がプリインストールされています。yq が使えることは覚えておく価値があります。既存のマニフェストにフィールドを足す・値を差し替えるといった編集を、エディタで開かずに済ませられるためです。開始直後に export do="--dry-run=client -o yaml" を設定しておくと、マニフェスト生成が速くなります。

あわせて、公式が明記している操作上の決まりが 5 つあります。1 つのタスクを終えたら base ノードへ戻ること（次のタスクでは別のホストを指定されます）。SSH 先からさらに別のホストへ SSH してはいけないこと。base ノードを再起動してはいけないこと（再起動しても試験環境は復旧しません）。root 権限が必要なときは sudo -i を使うこと。そしてターミナル内のコピーと貼り付けは Ctrl+Shift+C / Ctrl+Shift+V であることです（ターミナルの外では通常どおり Ctrl+C / Ctrl+V）。

もう 1 つ、知らないと試験画面を失う操作があります。入力中の単語を消すときは Ctrl+W ではなく Ctrl+Alt+W を使ってください。 試験はブラウザの中で動いているため、Ctrl+W を押すと Chrome が「タブを閉じる」と解釈します。ふだんターミナルで Ctrl+W を使っている人ほど、無意識に押してしまいます。

時間配分は「3 パス戦略」が有効です。①まず手早く解ける問題を先取りし、②次に複雑な問題に取り組み、③最後に全問を検証します。配点の高い D4〜D6 を優先するとよいでしょう。kube-apiserver.yaml などの static Pod マニフェストを編集する問題では、編集前に必ずバックアップを取る習慣をつけてください（この注意は第2回・第5回・第16回の実機手順で繰り返し扱います）。

仕上げの教材として Killer.sh があります。CKS の申し込みには模擬試験 2 回分が付属し（各 36 時間アクセス）、本番より難度が高めに作られています。本書を一通り終えてから挑むと効果が高く、合格者の多くが必須教材と位置づけています。後述するとおり AppArmor の実機演習は、CKS 試験と同じ Ubuntu ベースである Killer.sh で行う方針です。

第3巻で扱う技術スタックと 9 VM 環境#

第3巻は第2巻完走時点の 9 VM 環境をそのまま流用します。追加 VM は不要で、既存クラスタにセキュリティツールを段階投入していく形です。各 VM の役割と、第3巻で追加する要素は次のとおりです。

ツールは回ごとに段階投入します。kube-bench（第2回）→ seccomp / SELinux 強化（第6回）→ ホスト OS の攻撃面削減（第7回）→ OPA Gatekeeper / CEL（第8回）→ SealedSecrets（第9回）→ gVisor（第10回）→ Cilium（第11回・Calico から移行）→ Kubesec / KubeLinter（第12回）→ Trivy の CI 統合（第13回）→ bom / Cosign（第14回）→ Falco（第15回）という流れです。これにより fanclub-api を「動くアプリ」から「本番セキュリティ要件を満たすアプリ」へ少しずつ進化させます。

本書ラボでは、新しいツールのダウンロード元（github.com・quay.io/cilium・falcosecurity.github.io 等）を alma-proxy の whitelist に追加してから取得します。これは企業の出口制御プロキシ環境を再現する教育的な意図によるもので、各回で追加するドメインを明示します。

やってみよう：9 VM 環境の疎通確認 + kube-bench プレ実行#

第3巻の起点として、第2巻完走状態が正しく稼働しているかを確認し、kube-bench を一度走らせて現状のセキュリティスコアを可視化します。ここで取るのは「出発点のベースライン」です。第2回で CIS Benchmark の FAIL 項目を修復し、このベースラインからどれだけ改善したかを突き合わせます。前提状態は第2巻完走時点（9 VM・kubeadm HA 稼働中・SELinux は全ノード Enforcing）です。第3巻は破壊的な演習が続くので、ここでスナップショットを取っておいてください。

ステップ1：クラスタ全ノードの稼働確認#

実行コマンド：

$ kubectl get nodes -o wide

実行結果（例）：

NAME        STATUS   ROLES           AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                         CONTAINER-RUNTIME
k8s-cp-01   Ready    control-plane   12d   v1.36.2   192.168.1.125   <none>        AlmaLinux 10.2 (Lavender Lion)   containerd://2.2.6
k8s-cp-02   Ready    control-plane   12d   v1.36.2   192.168.1.126   <none>        AlmaLinux 10.2 (Lavender Lion)   containerd://2.2.6
k8s-cp-03   Ready    control-plane   12d   v1.36.2   192.168.1.127   <none>        AlmaLinux 10.2 (Lavender Lion)   containerd://2.2.6
k8s-wl-01   Ready    <none>          12d   v1.36.2   192.168.1.128   <none>        AlmaLinux 10.2 (Lavender Lion)   containerd://2.2.6
k8s-wl-02   Ready    <none>          12d   v1.36.2   192.168.1.129   <none>        AlmaLinux 10.2 (Lavender Lion)   containerd://2.2.6

VERSION 列がすべて v1.36.2（本書ラボのバージョン）で、全ノードが Ready であることを確認します。AGE は第2巻をいつ完走したかによって変わるため、読者の環境と一致しなくて構いません。KERNEL-VERSION 列は紙面の都合で省いていますが、実際には表示されます。

ステップ2：fanclub-api の稼働確認#

実行コマンド：

$ kubectl get pods -n fanclub

実行結果（例）：

NAME                               READY   STATUS    RESTARTS      AGE
fanclub-backend-849ff748f8-9wt4m   2/2     Running   0             57m
fanclub-backend-849ff748f8-b8dfr   2/2     Running   0             56m
fanclub-backend-849ff748f8-wlbs9   2/2     Running   0             56m
fanclub-db-0                       1/1     Running   0             60m
fanclub-frontend-7d9b4667f-6z44r   1/1     Running   5 (62m ago)   6d14h
fanclub-frontend-7d9b4667f-wnjxt   1/1     Running   6 (62m ago)   6d14h
fanclub-logcollector-486jq         1/1     Running   3 (65m ago)   6d14h
fanclub-logcollector-f7jlm         1/1     Running   3 (65m ago)   6d14h

第2巻完走時点の fanclub-api（Frontend / Backend / PostgreSQL）が Running であることを確認します。Backend が 2/2 なのは、アプリ本体（backend）にログ転送用のサイドカーコンテナ（log-shipper）が同居しているためです。fanclub-logcollector は第1巻で DaemonSet を学ぶ題材として追加したログコレクターで、ノード単位でログを集めます。第3巻ではこの fanclub-api を題材にセキュリティ強化を進めるため、起点で正常稼働していることが重要です。

ステップ3：alma-proxy の whitelist を確認する#

kube-bench は第3巻で最初に取得するツールです。取得先は GitHub Releases なので、alma-proxy の whitelist に次のドメインが登録されている必要があります。

まず登録状況を確認します。

実行コマンド（alma-proxy 上・root）：

# grep -nE 'github.com|githubusercontent.com' /etc/squid/whitelist.txt

実行結果（例）：

14:github.com
15:objects.githubusercontent.com
16:release-assets.githubusercontent.com
17:raw.githubusercontent.com
18:api.github.com
19:pkg-containers.githubusercontent.com

本書の環境では、これらは第2巻までの構築ですでに登録済みです。もし自分の環境で不足している場合は /etc/squid/whitelist.txt に 1 行 1 ドメインで追記し、systemctl reload squid で反映してください。whitelist.txt は他の講座と共用しているため、追記前に必ず重複を確認します。

ステップ4：Control Plane Node に kube-bench を導入する#

kube-bench は評価対象ノード上で実行します。ここでは Control Plane Node（k8s-cp-01）に導入します。本書執筆時点の最新版は v0.15.6 です。まず tar.gz を取得して展開します。

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

$ curl -sSL https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_linux_amd64.tar.gz | tar -xz
$ ls

実行結果（例）：

admin.conf  cfg  kube-bench

展開されるのは実行バイナリ kube-bench と、判定ルールを収めた cfg/ ディレクトリの 2 つです（ls に admin.conf も並んでいるのは、第2巻で k8s-cp-01 のホームに置いた kubeconfig の複製です）。cfg/ には 47 個のプロファイルが同梱されています。本書が使うのは CIS Benchmark の版番号を冠した cis-1.5 〜 cis-1.12 で、ほかに K8s のバージョン名を冠した旧命名（cis-1.20 / cis-1.23 / cis-1.24）、k3s・RKE2・microk8s 等の派生ディストロ向け、EKS・GKE・AKS 等のマネージドサービス向けが入っています。数字が似ていても系統が違う点に注意してください——cis-1.12 は CIS Benchmark v1.12 を指し、cis-1.24 は K8s v1.24 向けという意味です。

このダウンロードは alma-proxy 経由で行われます。github.com だけを許可しても、Release アセットの実体は objects.githubusercontent.com（移行中の新ホストは release-assets.githubusercontent.com）へ HTTP 302 でリダイレクトされるため取得に失敗します。ステップ3 でリダイレクト先まで確認したのはこのためです。なお、ノード側で http_proxy / https_proxy 環境変数が alma-proxy に向いていないと、curl は直接外部へ出ようとして失敗します。本書ラボでは第2巻で /etc/profile.d/proxy.sh にプロキシ設定を入れてあります。未設定の環境では https_proxy=http://alma-proxy:3128 curl ... のようにプロキシを明示してください。

次に、展開したファイルを標準的な場所へ配置します。この一手間が必要な理由は後述します。

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

# install -m 0755 /home/developer/kube-bench /usr/bin/kube-bench
# mkdir -p /etc/kube-bench
# cp -r /home/developer/cfg /etc/kube-bench/cfg
# kube-bench version

実行結果：

0.15.6

ステップ5：Control Plane Node で kube-bench をプレ実行#

実行の前に、root へ kubeconfig を教えておきます。kube-bench は評価対象クラスタの K8s バージョンを kubectl 経由で自動検出しますが、root は既定で kubeconfig を持たないためです。

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

# export KUBECONFIG=/etc/kubernetes/admin.conf
# kube-bench run --targets master

実行結果（冒頭部分）：

[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive (Automated)
[PASS] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)
[PASS] 1.1.3 Ensure that the controller manager pod specification file permissions are set to 600 or more restrictive (Automated)

実行結果（サマリ部分）：

== Summary total ==
39 checks PASS
10 checks FAIL
11 checks WARN
0 checks INFO

ここで指定した --targets master は、CIS Kubernetes Benchmark の第 1 章「Control Plane Security Configuration」を指します。ターゲット名が master なのは CIS Benchmark 側の章立てが旧来の呼称を使っているためで、評価される対象は Control Plane Node です。紛らわしいことに controlplane という別のターゲットも存在しますが、こちらは第 3 章「Control Plane Configuration」という別セクションで、認証・認可方針の手動確認項目しかありません。両者は新旧の言い換えではなく、別々の評価範囲です。

--targets を省略すると、そのノードで評価可能なターゲットすべてが実行されます。Control Plane Node では上記 5 つが走り、合計は 66 PASS / 12 FAIL / 53 WARN でした。

kube-bench は自動検出した K8s バージョンから、対応する CIS プロファイルを選びます。同梱の対応表は v1.34 が上限のため、ラボの v1.36.2 では「1.36 → 該当なし、1.35 → 該当なし、1.34 → cis-1.12」とマイナーを 1 つずつ下げて cis-1.12 に解決されます。前述のとおり CKS 試験環境の v1.35 も、同じ経路をたどって cis-1.12 に解決されます（1.35 → 該当なし、1.34 → cis-1.12）。プロファイルを固定したい場合や、kubeconfig を渡せない場面では --benchmark cis-1.12 と明示できます。KUBECONFIG を設定せずに実行すると Assuming default version 1.18 という警告が出るため、これが出たら kubeconfig かベンチマーク指定のどちらかが抜けていると判断してください。

この時点で FAIL や WARN が出ていて問題ありません。kube-bench の判定は、PASS（合致）・FAIL（要修正）・WARN（手動確認が必要）・INFO（参考情報）の 4 種です。第2回でこの FAIL 項目を一つずつ修復し、スコアを改善します。本回の目的は「現状の出発点を記録すること」です。

参考までに、本書ラボで FAIL となった 10 項目は次のとおりです。

[FAIL] 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (Automated)
[FAIL] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)
[FAIL] 1.2.15 Ensure that the --profiling argument is set to false (Automated)
[FAIL] 1.2.16 Ensure that the --audit-log-path argument is set (Automated)
[FAIL] 1.2.17 Ensure that the --audit-log-maxage argument is set to 30 or as appropriate (Automated)
[FAIL] 1.2.18 Ensure that the --audit-log-maxbackup argument is set to 10 or as appropriate (Automated)
[FAIL] 1.2.19 Ensure that the --audit-log-maxsize argument is set to 100 or as appropriate (Automated)
[FAIL] 1.2.30 Ensure that the --service-account-extend-token-expiration parameter is set to false (Automated)
[FAIL] 1.3.2 Ensure that the --profiling argument is set to false (Automated)
[FAIL] 1.4.1 Ensure that the --profiling argument is set to false (Automated)

kubeadm が既定で構築したクラスタでも、CIS 基準では 10 項目が未達だとわかります。監査ログ関連の 4 項目（1.2.16〜1.2.19）は第16回、暗号化関連の WARN は第9回で回収します。第2回では残りを修復します。

ステップ6：現状スコアをファイルに控える#

第2回での差分比較に備え、結果をファイルに保存しておきます。check ID 単位で「どの項目が PASS に転じたか」を突き合わせやすくなります。

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

# export KUBECONFIG=/etc/kubernetes/admin.conf
# kube-bench run --targets master > /root/cks-baseline-cp-01.txt

export KUBECONFIG を再掲しているのは、ステップ5 とは別のシェルで実行すると設定が引き継がれないためです。抜けたまま実行すると Assuming default version 1.18 の警告が出て、まったく別のプロファイルで評価された結果がファイルに残ります。ベースラインとして使えない記録になるので、必ず 2 行そろえて実行してください。

本回では修復は行いません。出発点の記録までで十分です。第2回でこのファイルと再実行結果を比較し、CIS 準拠化の効果を確認します。

fanclub-api セキュリティ強化の全体像（19 回プレビュー）#

第3巻を通じて、模擬アプリ fanclub-api は段階的にセキュアになります。各回で「何がセキュアになるか」を先に見ておくと、個々の技術が全体のどこに効くかを意識しながら学べます。

第2巻末: HA クラスタ + GitOps + 監視・ログ（動作する状態）

第3巻での進化:
 第2回:  CIS 準拠化（kube-bench で FAIL 項目を修復）
 第3回:  通信を default-deny で遮断し、メタデータ奪取経路を塞ぐ
 第4回:  RBAC を最小化し、SA トークンの自動マウントを止める
 第5回:  API Server の攻撃面を削り、脆弱性回避のため更新する
 第6回:  seccomp + SELinux で OS 層を多層に固める
 第7回:  ノードの不要サービス・権限・外部通信を削る
 第8回:  PSS Restricted を強制し、危険な Pod を弾く
 第9回:  DB パスワードを暗号化し、etcd 内も暗号化する
 第10回: 高リスクワークロードを gVisor で隔離する
 第11回: Pod 間通信を WireGuard で透過的に暗号化する
 第12回: イメージを最小化し、マニフェストの弱点を静的解析で潰す
 第13回: イメージの脆弱性をスキャンして修正する
 第14回: SBOM を生成し、イメージに署名して出所を保証する
 第15回: 不審な shell 実行をリアルタイムで検知する
 第16回: 監査ログで不審操作を追跡し、攻撃フェーズを特定する
 第17回: 6 面の検知体制を点検し、不変性とアラートで仕上げる
 第18回: 検知から復旧・振り返りまでを一気通貫で対応する
 第19回: 試験直前対策で総ざらいし、CKS 受験準備完了を宣言する ★

第18回では、深夜に Falco が「Backend コンテナ内で bash が実行された」と発報するシナリオを通じ、検知から隔離・復旧・ポストモーテムまでを実践します。第15回（Falco）・第16回（監査ログ）・第17回（多面的検知）で学んだスキルを統合する回です。

Kubestronaut 5 冠ロードマップ#

三部作の完走で、実技 3 資格（CKAD / CKA / CKS）の受験準備が整います。残る KCNA・KCSA は多肢選択式で、自習による短期取得が可能です。この 5 資格すべてを有効に保持すると、Linux Foundation から Kubestronaut として認定されます。

本書（第3巻）は全 19 回で KCSA（Kubernetes and Cloud Native Security Associate）の出題範囲を大きくカバーします。4C モデルと脅威モデルは本回（第1回）で、攻撃フェーズの特定は第16・18回で、6 面にわたる脅威検知は第17回で扱います。CKS 取得後に KCSA を続けて受けると、知識が新しいうちに効率よく合格を狙えます。5 冠取得後に CNCF へ申請すると、Kubestronaut バッジ・ジャケット・コミュニティ参加資格が授与されます。なお CARE プログラムには経路が 3 つあります。CKA または CKAD を取得・再認定すると KCNA が、CKS を取得・再認定すると KCSA が current に更新され（いずれも 2026 年 1 月 1 日から）、さらに 2026 年 6 月 18 日以降は CKS が CKA の有効期限も延長します。つまり 5 冠を維持するために実際に受け直すのは CKAD と CKS の 2 つで足ります。維持コストは以前より大きく下がっています。

外部リンク：Kubestronaut プログラム公式（CNCF）

暗記必須コマンド（第1回）#

CKS 試験中は、許可された 8 件以外の公式ドキュメントを参照できません。本書では各回末に、その回で扱った「試験中に参照できないツール」のコマンドを積み上げていきます。第1回で扱った kube-bench は許可ドキュメントに含まれず（github.com も参照不可）、コマンドを手に覚えておく対象です。本格的な使い方は第2回で扱いますが、取得と実行の形をここで押さえます。

curl -sSL https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_linux_amd64.tar.gz | tar -xz
export KUBECONFIG=/etc/kubernetes/admin.conf
kube-bench run --targets master
kube-bench run --targets node
kube-bench run --targets master --benchmark cis-1.12
kube-bench run --targets master --config-dir /home/developer/cfg

1 行目はバイナリの取得です。2 行目は root で実行する際の kubeconfig 指定で、これがないとバージョン自動検出に失敗します。3 行目が Control Plane Node の本体評価（CIS 第 1 章）、4 行目が Workload Node の評価（第 4 章）です。5 行目は CIS プロファイルを明示する形で、kubeconfig を渡せない場面での代替手段になります。6 行目は標準パスへ配置せず、tar を展開したディレクトリのまま実行する場合の形です。パスは ~/cfg ではなく絶対パスで書いてください——kube-bench はファイル権限を見るため root で実行しますが、sudo 下では ~ が /root に展開され、展開先の /home/developer/cfg を指さなくなります（結果は config file is missing 'version_mapping' section というエラーです）。

まとめ#

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

• CKS は「クラスタを守る・脅威を検知する」資格であり、CKA 合格が受験の前提である
• CKA（建てる・運用する）から CKS（守る・検知する）へ思考様式が変わり、防御は 4C（Cloud / Cluster / Container / Code）の各層を多層で固める
• CKS は 6 ドメイン構成で、D4・D5・D6（各 20%・計 60%）が学習の重心である
• 試験中に参照できる公式ドキュメントは 8 件のみで、Trivy・AppArmor 等はコマンド暗記が必要である
• 本書ラボは K8s v1.36.2（第2巻継承）、CKS 試験環境は v1.35 であり、差は 1 マイナー（CIS プロファイルはどちらも cis-1.12 に解決されるため一致する）
• CKS は CKA・CKAD と違い、タスクごとに指定された SSH ホストで作業する。参照可能な 8 件はサブパスまで限定され、helm.sh/docs は CKS では開けない
• 9 VM 環境で kube-bench を --targets master でプレ実行し、現状スコアのベースライン（39 PASS / 10 FAIL / 11 WARN）を取った
• 三部作完走 + KCNA + KCSA で Kubestronaut 5 冠に到達できる

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

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

1. CKS は CKA を取得していなくても受験できる
2. CKS の 6 ドメインのうち、配点が最も大きいのは Cluster Setup である
3. CKS 試験中は kubernetes.io のほか Falco・Cilium・etcd 等の公式ドキュメントを参照できる
4. CKS 試験中に Trivy の公式ドキュメントを開いてオプションを調べられる
5. CKS の試験環境で動いている K8s は本書ラボ（v1.36.2）より新しい
6. kube-bench で Control Plane Node の起動フラグやファイル権限を評価するには --targets controlplane を指定する
7. Kubestronaut は CKAD・CKA・CKS・KCNA・KCSA の 5 資格を有効保持すると認定される
8. CKA は「クラスタを建てる・運用する」、CKS は「クラスタを守る・脅威を検知する」に重心がある
9. 4C セキュリティモデルは Cloud / Cluster / Container / Code の 4 層からなる

解答と解説

1=×／2=×／3=○／4=×／5=×／6=×／7=○／8=○／9=○

主要な問題の解説です。問2 の最大配点は D4・D5・D6（各 20%）で、Cluster Setup は 15% です。問4 は、Trivy・AppArmor・gVisor・OPA Gatekeeper・Cosign の公式サイトが試験中は参照不可のため誤りで、これらはコマンドの暗記が必要です。問6 は --targets master が正解です。controlplane は CIS 第 3 章「Control Plane Configuration」という別セクションを指し、手動確認項目しか含まれません。なおプレ実行の時点で FAIL や WARN が出ているのは想定どおりで、第2回で修復します。問5 は逆で、試験環境は v1.35、本書ラボは v1.36.2 とラボのほうが 1 マイナー新しい状態です（カリキュラム文書の版 v1.34 と試験環境のバージョンは別物である点にも注意してください）。問9 の 4C は外側から Cloud → Cluster → Container → Code の同心円で、外側の層が破られると内側の防御だけでは守りきれないため、各層を多層で固めます。

次回予告#

第2回「kube-bench + CIS ベンチマーク修復 + バイナリ検証」では、本回でプレ実行した kube-bench を使い、CIS Kubernetes Benchmark の FAIL 項目を一つずつ修復します。kube-apiserver のフラグ・etcd 設定・kubelet 設定・ファイルパーミッションを直し、本回で取ったベースラインからのスコア改善を確認します。あわせてプラットフォームバイナリ（kubectl / kubelet）の SHA256 検証を扱い、CKS D1（Cluster Setup・15%）の前半を固めます（NetworkPolicy・TLS Ingress は第3回）。

→ 詳しくは 第2回 kube-bench + CIS ベンチマーク修復 + バイナリ検証