Certified Kubernetes Security Specialist (CKS) #19: 試験のコツと時間管理、よく間違えるパターン

#1 から #18 まで 6 つのドメインをすべて整理しました。この記事は 実技試験に入る直前にもう一度読んでいく圧縮版 です。新しいドメインはなく、2 時間の実技をどう運用するかと、シリーズ全体でセキュリティ作業が最も点数を落としやすい罠だけを集めました。選択式ではなく実際のクラスターを空のターミナルからより安全に変える試験なので、同じ知識でも運用が合格と不合格を分けます。

2 時間の運用戦略 #

作業単位での運用 #

CKS は約 15〜20 個の作業を 2 時間で解かなければなりません。選択式のように設問ごとに均等に時間を分けるのではなく、作業ごとに配点が画面に表示されるので、その配点がそのまま優先順位 になります。CKS の特徴は作業ごとに要求するツールが違う点です。ある作業は AppArmor を、次の作業は Trivy を、その次は Falco ルールを扱うという具合なので、手に馴染んでいないツールに出会うと 1 つの作業で丸ごと詰まりやすいです。

時間管理の最初のルール #

1 つの作業に入れ込みすぎません。 配点に比べて時間がかかりそうなら、ひとまず可能なところまで作っておいて flag して次へ進みます。合格ラインは 67% なので、難しい 1〜2 個の作業を捨ててもかまいません。初めて見るツールの作業 1 つにこだわって、手に馴染んだ NetworkPolicy・RBAC の作業を 2〜3 個取りこぼすのが最もよくある失敗です。

手に馴染んだツールから #

CKS はツールごとの試験なので、作業ごとに難易度の差が大きいです。作業リストを最初から最後まで一度ざっと眺めながら、配点に対する難易度 を頭の中で印付けします。NetworkPolicy default deny、RBAC 最小権限、PSA label のように手順が決まっていて手に馴染んだ作業を先に処理して点数を素早く積み上げます。AppArmor プロファイルのノードへのロード、seccomp のパス指定、Falco ルールの作成のように手間がかかったりノードの中で解いたりする作業を途中に配置する運用が合格ラインを超える道です。

セットアップの再整理 #

#1 で組んだセットアップを試験開始直後 1 分以内に終わらせます。CKS も kubectl で解く作業が少なくないので、CKA・CKAD と同じ速度セットアップがそのまま点数になります。

# kubectl を k に
alias k=kubectl

# dry-run + YAML 出力を do に
export do="--dry-run=client -o yaml"

# 即時削除を now に (Pod を素早く消して作り直すとき)
export now="--force --grace-period=0"

# 自動補完 (k まで拡張)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

~/.vimrc には YAML インデント事故を防ぐ設定を入れます。CKS は seccomp・AppArmor のパスや securityContext のフィールドのように 1 マスずれただけで適用されないマニフェストをよく編集するので、いっそう重要です。

set expandtab
set tabstop=2
set shiftwidth=2
set number

YAML ブロックを丸ごとインデントするときはビジュアルモード (V) で行を選択してから > で 1 段下げ、. で繰り返します。ドキュメントから securityContext や PSA label のスニペットをコピーして貼るときは自動インデントが干渉するので、貼り付ける直前に :set paste を入れます。

context 切り替えを真っ先に行う #

CKS も CKA と同じく クラスターが複数 あり、各作業は指定されたクラスターで解かないと採点されません。作業説明の一番上に提示される use-context コマンドを 先に実行 しないと、プロファイルを正しく作ったりポリシーを正しく適用したりしても、別のクラスターで作業して 0 点です。

# 作業ごとに真っ先に実行
k config use-context <作業で指定されたコンテキスト>

# 今どのクラスターかを確認
k config current-context

CKS はノードの中に入る作業の比重が CKA より大きいです。AppArmor プロファイルのロード、seccomp プロファイルファイルの配置、kernel パラメータの調整、Falco のインストール・ルール修正のような作業は 指定されたノードに SSH で入ってから 解かなければなりません。control plane ノードでやるべき作業をワーカーノードでやると点数がありません。

# 作業で提示されるホスト名で接続
ssh node01

# 作業が終わったら必ず抜けて元の環境に戻る
exit

SSH でノードに入ったまま次の作業を解き始めるミスがよくあります。ノード作業が終わったら exit で抜ける ことを 1 つの動作にまとめておく習慣が誤答を防ぎます。ノードに入った状態で kubectl 作業を始めると、見当違いの環境に作られます。

公式ドキュメントを素早く活用する #

CKS は試験中に kubernetes.io/docs だけでなく Falco・Trivy・AppArmor・gVisor のような指定ツールの公式ドキュメント閲覧が許可されます。セキュリティツールは文法とオプションが長く覚えにくいので、ドキュメント活用が CKA よりさらに決定的です。ただし運用に 2 つの原則があります。

• ドキュメントの場所を事前に身につけておきます。 試験会場で初めてドキュメント構造を把握すると時間を丸ごと失います。seccomp プロファイルの例が kubernetes.io のどのページにあるか、Falco ルールの文法が falco.org のドキュメントのどこにあるか、Trivy の重大度オプションと AppArmor プロファイルの文法が各ドキュメントのどこにあるかを、普段から手に馴染ませておきます。
• ドキュメントの時間も試験時間です。 ドキュメントを探している間もタイマーは進みます。NetworkPolicy・RBAC のように generator や覚えたパターンで即座に作れる作業はドキュメントを開かず、ドキュメントはプロファイルの文法やツールのオプションのように覚えにくい部分だけを確認する用途で使います。

ドキュメントから YAML スニペットをコピーするときはインデントが付いてくるので、貼り付けた直後に :set paste で自動インデントの干渉を切るのが安全です。

よく間違えるパターン #

セキュリティ実技で点数を落とす定番パターンです。知識不足よりも運用ミスとツールごとの手順漏れで失う点数のほうが多いです。

1) context と namespace の未切り替え #

各作業は指定されたクラスターとネームスペースで解かないと採点されません。作業説明に提示される use-context コマンドを先に実行しないと、答えを正しく作っても別のクラスターで作業して 0 点です。CKS はクラスターが複数あるので、このミスが特に多いです。

k config use-context <作業で指定されたコンテキスト>
k config set-context --current --namespace=<作業のネームスペース>

2) AppArmor プロファイルのノードへのロード漏れ #

AppArmor 作業で最もよくある失点です。プロファイルをマニフェストに参照だけ張って 当該ノードにプロファイルをロードしないと、Pod が起動できなかったり強制が適用されなかったりします。プロファイルファイルをノードに配置してから apparmor_parser でカーネルにロードし、Pod の securityContext でそのプロファイルを参照して初めて 1 つの作業が完成します。

# 指定されたノードで: プロファイルをカーネルにロード
ssh node01
sudo apparmor_parser -q /etc/apparmor.d/custom-profile
# ロード状態を確認
sudo aa-status | grep custom-profile
exit

# Pod securityContext でロードされたプロファイルを参照
securityContext:
  appArmorProfile:
    type: Localhost
    localhostProfile: custom-profile

3) seccomp プロファイルのパスの混同 #

seccomp プロファイルは kubelet の seccomp ルートディレクトリ基準の相対パス で指定します。デフォルトのルートは /var/lib/kubelet/seccomp で、プロファイルファイルをこのディレクトリの下に置き、localhostProfile にはそのルート基準の相対パスだけを書きます。絶対パスを書いたりファイルを見当違いの場所に置いたりすると Pod が起動できません。

# プロファイルを kubelet seccomp ルートの下に配置
sudo mkdir -p /var/lib/kubelet/seccomp/profiles
sudo cp audit.json /var/lib/kubelet/seccomp/profiles/audit.json

# ルート (/var/lib/kubelet/seccomp) 基準の相対パスだけを記入
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/audit.json

4) PSA label のタイプミスとモードの混同 #

Pod Security Admission はネームスペースの label で制御します。label キーの接頭辞 (pod-security.kubernetes.io/)、モード (enforce・audit・warn)、レベル (privileged・baseline・restricted) を正確に書かなければなりません。キーを 1 文字でも間違えると admission が動作せず、enforce を使うべきところに warn だけを張ると危険な Pod がそのまま通過して点数がありません。

k label ns prod \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

5) etcd 暗号化後の再暗号化漏れ #

etcd の保存データの暗号化は、EncryptionConfiguration を作って apiserver に --encryption-provider-config で接続するだけでは終わりません。設定の適用は それ以降に書かれる Secret だけを暗号化 するので、すでに平文で保存された既存の Secret は一度書き直して初めて暗号化されます。この再暗号化の段階を抜かすと既存の Secret が平文のまま残り、点数が引かれます。

# 設定を適用した後、既存の Secret をすべて書き直して再暗号化
k get secrets --all-namespaces -o json | k replace -f -

6) Trivy の重大度・終了オプションの漏れ #

イメージスキャン作業では「HIGH と CRITICAL の脆弱性があるイメージを見つけて削除せよ」という型がよく出ます。--severity HIGH,CRITICAL で重大度を限定しないと結果が多すぎて判別が難しく、自動判定が必要なら --exit-code 1 で終了コードを活用します。重大度の表記はカンマで詰めて書き、空白を入れません。

# 指定の重大度だけ、結果を簡潔に
trivy image --severity HIGH,CRITICAL --quiet nginx:1.19

# 脆弱性があれば終了コード 1
trivy image --exit-code 1 --severity CRITICAL nginx:1.19

7) ポリシー適用ネームスペースの混同 #

OPA/Gatekeeper・Kyverno のポリシーや NetworkPolicy は どのネームスペースに適用されるか が核心の条件です。NetworkPolicy は作ったネームスペースだけに適用され、Kyverno のポリシーは ClusterPolicy かネームスペース限定の Policy かによって範囲が違います。作業が指定した対象範囲とポリシーの適用範囲がずれると、意図した遮断が起きません。

# NetworkPolicy は作ったネームスペースの中だけで動作
k get networkpolicy -n target-ns

8) ノード SSH 後の戻り漏れ #

System Hardening ドメインはノードに直接入って解く作業が多いです。AppArmor のロード、seccomp ファイルの配置、kernel パラメータ (sysctl) の調整をノードで終えた後 exit で抜けないと、次の作業の kubectl コマンドがノード環境で実行されて見当違いの場所に作られます。ノード作業は ssh → 作業 → exit を 1 つのまとまりとして運用します。

9) 変更後の適用・再起動漏れ #

apiserver の --encryption-provider-config や admission plugin を追加するには /etc/kubernetes/manifests/kube-apiserver.yaml を直さなければならず、直した後は kubelet が static Pod を立て直すまで待って初めて反映されます。Falco ルールを変えた後はサービスを再起動して初めて新しいルールが適用されます。設定変更は適用・再起動までを 1 つの動作にまとめます。

# apiserver static Pod が立て直されたかを確認
k get pods -n kube-system | grep apiserver
# Falco ルールを適用
sudo systemctl restart falco

部分点と検算 #

CKS は作業単位で採点され、一部の作業には部分点があります。ツール作業は「作った」ではなく「実際に適用されて遮断・検知が動作するか」まで確認しなければなりません。作業を終えるたびに短く検算します。

# 作ったポリシー・リソースが実際に起動したか
k get networkpolicy,pod -n <namespace>

# PSA が危険な Pod を実際に拒否するか (拒否されれば正常)
k run test --image=nginx --privileged -n prod

# AppArmor プロファイルがノードにロードされたか
ssh node01 'sudo aa-status | grep custom-profile'

# apiserver が新しい設定で立て直されたか
k get pods -n kube-system | grep apiserver

検算は 30 秒で終わりますが、「やったと思った作業が実は適用されていなかった」という最もよくある失点を防ぎます。特に apiserver マニフェストを直した後は kubelet が新しい Pod を立てるのに数秒かかるので、k get pods -n kube-system をもう一度確認します。

紛らわしい概念ペア #

作業中に瞬間的に混同しやすいセキュリティの概念ペアを 1 行の違いに圧縮します。

AppArmor と seccomp はよく 1 つの作業に一緒に出ますが、防ぐ対象が違います。seccomp はコンテナが呼び出せる システムコールの集合 を狭め、AppArmor はファイルパス・ネットワーク・capability のような リソースアクセス をプロファイルで制限します。どちらもホストカーネルの上で動作する一方、gVisor は別のユーザー空間カーネルを置いてコンテナをホストカーネルからもう一層引き離します。

ドメインごとの受験直前チェックリスト #

各ドメインで手がすぐ出なければならない核心のコマンドと手順です。

ドメイン 1: Cluster Setup (10%) #

• NetworkPolicy: default deny の後に必要な ingress/egress だけ、podSelector・namespaceSelector
• kube-bench で CIS benchmark を点検、指摘項目を修正
• Ingress TLS: tls ブロックと Secret (kubernetes.io/tls) を接続
• バイナリ検証: チェックサム・署名を確認

ドメイン 2: Cluster Hardening (15%) #

• RBAC 最小権限: Role/ClusterRole、必要な verb・resource だけ、k auth can-i
• ServiceAccount トークン: automountServiceAccountToken: false
• API アクセス制限: anonymous-auth、NodeRestriction admission
• クラスターのアップグレードで既知の脆弱性をパッチ

ドメイン 3: System Hardening (15%) #

• AppArmor: apparmor_parser でノードにロード、securityContext.appArmorProfile
• seccomp: /var/lib/kubelet/seccomp の下に配置、ルート基準の相対パス
• capabilities の最小化 (drop: ["ALL"])、/proc の保護
• ノード ssh 作業は exit での復帰まで 1 つのまとまり

ドメイン 4: Minimize Microservice Vulnerabilities (20%) #

• PSA: pod-security.kubernetes.io/enforce label、レベル・モードを正確に
• Secrets: EncryptionConfiguration、既存 Secret の再暗号化
• gVisor: RuntimeClass で runsc handler を指定
• Pod 間 mTLS: Cilium ポリシーで暗号化・身元検証

ドメイン 5: Supply Chain Security (20%) #

• Minimal images: distroless・scratch、不要なパッケージを除去
• Trivy スキャン: --severity HIGH,CRITICAL、--exit-code
• cosign で署名・検証、SBOM を生成
• admission で未署名・脆弱なイメージを拒否

ドメイン 6: Monitoring, Logging and Runtime Security (20%) #

• OPA/Gatekeeper・Kyverno でポリシーを強制、適用範囲を確認
• Falco ルールの作成・トリガー、ログ確認、ルール変更後の再起動
• audit policy の作成、apiserver --audit-policy-file・--audit-log-path を接続
• container immutability (readOnlyRootFilesystem)、forensics の手順

オンライン監督受験の直前点検 #

CKS は PSI のリモートターミナルに接続して作業するオンライン監督試験です。試験開始前に次を確認します。

身分証 #

• 英文表記のある身分証 (パスポート推奨)、名前が登録情報と正確に一致
• 監督官のチャット案内に従って身分証の両面をカメラに提示

受験環境 #

• 机の上のすべての物を片付け、壁面のメモ・ポスターを除去
• デュアルモニターは 1 台だけ使用、補助画面を分離
• 家族・ルームメイトの出入りを遮断、静かな単独空間を確保

システム #

• 受験 30 分前に入室してシステム点検を通過
• バックグラウンドアプリ・通知・VPN を終了、安定した有線ネットワークを推奨
• 試験開始後に真っ先に alias k・do・自動補完・.vimrc のセットアップ、最初の作業の前に context を確認

まとめ #

この記事で押さえたこと:

• 2 時間の運用。 作業ごとの配点が優先順位。手に馴染んだツールの作業から、初めて見るツールで詰まったら flag して次へ、入れ込みすぎ禁止
• ツールごとの作業。 CKS は作業ごとにツールが違うので 1 つの作業で詰まりやすい。手に馴染んだものから点数を積み上げる
• セットアップ。 alias k・do・now・自動補完・vim インデントを開始 1 分以内に
• context 最優先。 CKS はクラスターが複数あってノード作業が多い。作業ごとに use-context を先に、ノード作業の後は exit
• ドキュメント活用。 kubernetes.io と Falco・Trivy・AppArmor・gVisor のドキュメントの場所を事前に身につけておき、ドキュメントの時間も試験時間
• 定番のミス。 context/namespace、AppArmor のノードへのロード、seccomp のパス、PSA label のタイプミス、etcd の再暗号化、Trivy の重大度オプション、ポリシー適用ネームスペース、ノードからの復帰、適用・再起動漏れ
• 部分点と検算。 作れるところまで作り、実際に遮断・検知が動作するかを確認
• 紛らわしい概念ペア、6 つのドメインごとの核心手順、オンライン監督の点検

次へ — フルスケール実技模擬試験 #

最後の記事です。

#20 フルスケール実技模擬試験 (全ドメイン統合シナリオ + 解説) では、実際の試験に近いドメイン分布で統合シナリオを解き、詳しい解説を付けます。試験環境のように時間を計って解いてみて、比重の大きい後半 3 ドメイン (マイクロサービス・サプライチェーン・ランタイム) をもう一度固める最後の段階です。