CKS試験直前メモ

2026/09現在、CKS(Certified Kubernetes Security Specialist)のためにできるようにしておいたことを試験前に整理する。

CKS公式情報

公式情報ではこれらが特に役立つ。試験範囲を把握することで勉強を進めやすくなるというのと、特にCKSではKubernetes document以外のリソースも参照が許可されているため適宜参照すると良い。

また、SBOM生成のbom、CNIのcilium、Ingress ControllerのIngress Nginxなどは、他のソフトウェアも選択できる中でそれらのリンクが記載されていることから、実際に手を動かす際には記載のあるソフトウェアを優先すると良さそう。

結構重要だが、意外とUdemyやKodekloudなどでは言及されていない気がする？

項目ごとの整理

CKSではsecurity enhancementのための周辺ソフトウェアが多数登場する。混乱したときに立ち返って軽く確認すると良い。

app_armor

Linux自体に備わっている機能をcontainerに適用する。

containerを実行するNodeでapparmor_parser <profile>を行いapp_armor_profileをloadする。

aa-statusによってapp_armor profileが読み込まれていることを確認する。ここで表示されるprofile名はファイルの中身から確認すること。

Kubernetes manifestではPodのsecurityContextとして指定することができる。

seccomp_profile

Pod / containerが呼び出すことができるsyscallを制限する設定。

Kubernetes manifestではPodのsecurityContextとして指定することができる。

typeによってpre-definedなルールセットを利用するか、自前で定義したLocalhostのものを使用するかを選択することができる。

Localhostの場合は規定で/var/lib/kubelet/seccomp/profiles以下にprofileを格納する必要がある。

falco

runtimeでsuspeciousなsyscallを検知してログに出力することができる。

既存のfalco_ruleが多く/etc/falco以下に存在しているため、それらと公式ドキュメントをあわせてlocalファイルにルールを追記できるようにしておく。

falcoがsystemdで起動している場合は、設定を行ったあとはfalco自体のreloadをSIGHUPで行うことを忘れずに。

kube-bench

実行したNode内で、Kubernetes関連の設定ファイルの権限設定などのCIS Kubernetes Benchmarkに反する設定項目を検知する。

e.g.

kube-bench run --config-dir /opt/kube-bench/cfg

kubesec

PodなどのKubernetes manifestを引数に取り、securityContextなどのsecurity周りの設定値をチェックするコマンド。

e.g.

kubesec scan pod.yaml

Pod Security Standard / Admission

Pod Security Standards

Kubernetes namespaceに特定のlabelを付与することによって、そのnamespace配下に新規作成されるPodに対してPod Security Standardを施すことができる。(施す仕組みがPod Security Admission)

設定のstrictnessと、違反したときの挙動をlabelで指定する形。

e.g.

kubectl label namespace my-ns \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

bom

tar archiveからimageのSBOM(Software Bill of Materials)を作成することができる。

SBOM関連では他にもTrivy, Syft, Grypeなどがある。

e.g.

bom generate --image-archive <image archive file> --format <format>

Kubernetes manifest関連

Projected Volume

serviceAccountToken projected volumes

expirationやaudienceの値を設定しながらservice accountのtokenをPodにmountすることができる。

PodへのServiceAccountの指定、automountServiceAccountToken: falseの指定と併せて使用することが多い。

NetworkPolicy

基本的な書き方はKubernetes公式documentのexampleを見れば良い。

以下のnamespaceSelectorとpodSelectorはAND

  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          team: blue
      podSelector:
        matchLabels:
          role: client

以下のnamespaceSelectorとpodSelectorはOR

  - from:
    - namespaceSelector:
        matchLabels:
          team: blue
    - podSelector:
        matchLabels:
          role: client

となるので読み書きの際に注意。

fromの中でANDとORを表現できるなら複数のfromは要らないのではと思ってしまうが、portsを分けつつ記載するために必要。

CiliumNetworkPolicy

Cilium自体のdocumentを参照することができるため、基本的には記載のある例からformatを借用すると良い。

対象のclusterにはすでにCiliumNetworkのCRDが存在するため、以下のコマンドでサッと使用を確認することも可能。

kubectl explain ciliumnetworkpolicy

Istio

CKSでは主にPod間のmTLSの文脈で使用する。

PeerAuthenticationのリソースをnamespace以下に適用することで、namespace以下のmTLS設定を有効化することができる。

以下はmode: STRICTで指定して設定を適用しているため、namespace: foo以下ではmTLSが強制されている。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT

istioの管理namespace(通常はistio-system)に対してPeerAuthenticationを作成することでservice mesh全体に適用することができる。

mTLSを有効化するために、Sidecar modeでは対象のPodにsidecarをinjectionする必要がある。

kubectl label namespace production istio-injection=enabled

既存Podには自動では適用されないため、Podの再生成が必要となる。

AdmissionWebhook

ImagePolicyWebhook

事前準備としてはImagePolicyWebhookに対応できるようにしておいた。

kube-apiserverからimage policy webhook backendへの接続情報はkubeconfig formatの設定ファイルに記載し、AdmissionConfigurationに設定ファイルへのパスを記載する。AdmissionConfigurationファイル自体は--admission-control-config-file引数でkube-apiserverに渡す。設定ファイルはkube-apiserverのPodへ適切にmountすること。

あとは全般的なこととして、kube-apiserverのstatic manifestを操作する際にはyamlのbackupを取っておくと良い。

Auditing

以下をkube-apiserver二適切に設定できるようにしておく。policy-fileやlog-pathはvolumes, volumeMounts二設定することを忘れずに。

--audit-policy-file
--audit-log-path
--audit-log-maxage
--audit-log-maxbackup
--audit-log-maxsize

Audit policy自体は、公式ドキュメントに記載の例を参考にすればだいたい書ける。Policy更新後にkube-apiseverのPodを再生成することを忘れずに。

Secret (Etcd encryption)

Encrypting Confidential Data at Rest

例にあるEncryptionConfigurationのファイルを作成する。
適切にkube-apiserverのPodにmountしつつ--encryption-provider-configとしてkube-apiserverの引数として渡す。

既存のsecretなどのリソースを暗号化する必要がある場合は以下のコマンドで、公式ドキュメントページの下部に同じ記載がある。

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

tips: configmapをsecretに変換する際にはstringDataというSecret作成用のkeyを使うと良い。自前でbase64変換を行う必要がなくなる。

Kubernetes 便利コマンド集

impersonation

kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<name> # service account
kubectl auth can-i --list --as=alice --as-group=developers # user & group

resourceに対して行うことができるverbやapi groupを確認する際に使用。

kubectl api-resources -o wide

各manifest設定値の説明を参照する場合に使用。結構使う。

kubectl explain pod.spec

kube-apiserverへの接続情報の確認

kubectl config view --raw

(コマンドじゃないが) instantにPodのNodeを指定したい場合はnodeにlabel & node selectorでもよいが、nodeNameに直接記載しても良い。実務でもdebug時にはいいかも？

kind: Pod
spec:
	nodeName: hoge-node

Linux 便利コマンド集

secretの中身だけ手で作るとき、-nオプションがないと改行が入ってしまうので注意。

echo -n 'hoge' | base64

systemd関連

systemctl cat hoge.service
systemctl edit hoge.service
systemctl daemon-reload # 変更されたUnit定義をsystemdに再読み込みさせる。
systemctl restart hoge.service # 新しいUnit定義でプロセスを再起動する。
systemctl status hoge.service

ログ確認

journalctl -fu hoge.service

systemdファイルの編集 editor指定結構重要。(emacs使えない)

EDITOR=vim systemctl edit hoge.service

NodeのLinuxカーネルが出力したメッセージを確認するコマンド。app_armorなどによってPod内の操作が拒否された場合にその詳細を確認することができる。

dmesg --follow