はじめに
先日、Kubernetes 認定試験 の中でも最難関とされている Certified Kubernetes Security Specialist（CKS） に一発合格したので、勉強した内容や試験対策についてまとめたいと思います。
| CKS 認定証明 | スコア |
|---|---|
 |
 |
CKS は Kubernetes だけでなく、Linux やセキュリティに関する周辺領域も対象としており、出題内容は広範囲にわたります。
公式的に出題されるドメインはリストアップされているものの、具体的にどういった内容の問題が出題されるのかについてまとまった記事が見つからず苦戦したため、本記事では自身が模試で遭遇した問題や実際の本番試験で問われた内容をもとにまとめておきます。
※ 本内容は 2026 年 2 月時点のものです。CNCF 関連の試験は問題が頻繁に更新されるので、あくまで参考程度に読んでください。
前提
CKS は CNCF が提供する Kubernetes セキュリティに特化した認定試験です。
| 項目 | 内容 |
|---|---|
| 前提 | Certified Kubernetes Administrator（CKA）に合格している必要がある |
| 試験時間 | 2 時間 |
| 出題問題数 | 15〜20 問 |
| 出題形式 | 実技試験（Kubernetes を実行するコマンドラインから複数のタスクを解く） |
| 言語 | 英語 |
CKS は Kubernetes 認定試験（Kubestronaut Program）の中でも最難関とされている資格試験です。実際、Kubernetes に普段から精通している人でも CKS は難しかったという声を耳にします。
こう言われる理由は端的に以下の 3 点にあると思いました。
試験内容が Kubernetes で完結しない
Linux の基本的な仕組みや標準コマンドの使い方を理解している必要がある。
Kubernetes に関して一歩踏み込んだ知識が要される
Kubernetes が内部的にどのような挙動を取っていて、脆弱性となり得る点は何なのかを確実に理解しておく必要がある。
セキュリティに関する専門的な知識
CNCF をはじめとするセキュリティソリューションやプラクティスのデファクトスタンダードついて、概要、コマンドの実行方法、構成ファイルの書き方・読み込み方法等を理解している必要がある。
このためか、CKS 自体は CKA（Certified Kubernetes Administrator） に合格していないと、そもそも受験資格すら与えられません。
CKA に受かっていればある程度 Kubernetes の基本的な操作やワークロードのデプロイ方法については理解していると思います。
しかし、CKS では実際にそれらの操作の裏側でどのようなプロセスが走っているのかについても理解が必要です。以下のブログでは、Kubernetes（コンテナ仮想化技術）を構成する Linux の関連技術についてまとめています。
また、Linux の基本的な仕組みについては以下の本がお勧めです。（愛読書）
CKS は、Linux のコマンド（例：ユーザ管理やファイルシステム）を理解している必要がありますが、ここでキャッチアップするというより前提知識として知っている必要があります。
学習ロードマップ
CKS の試験対策としては以下がお勧めです。
まず、KodeKloud というサイトで出題範囲と試験で扱われる内容について一通りキャッチアップします。講義動画はかなり細かいのでどのソリューションで何ができるのかをざっくり理解するようにします。
KodeKloud には Mock Exam（模擬試験）が用意されているので、自力で解けるようになるまで反復します。
その後、CKS 試験購入時点で付いてくる Killer Shell というサイトで模擬試験を解きます。
こちらは A と B があり、いずれも 36 時間限定でアクセスが可能です。体感では B 試験は A 試験よりかなり難しい印象です。
Killer Shell は制限時間があるため本番試験の直接に受けるのがお勧めです。
KodeKloud
KodeKloud の Standard プランを購入すると以下の全てにアクセスできます。
Standard プランは 月額 35 USD（5,000〜6,000 円程度）ですが、仮に認定試験に 2 回連続で落ちてしまった時のことを考えると圧倒的に安いので、こちらは有無を言わせず購入することをお勧めします。
また、こちらのプランを購入することで、認定試験の 30% OFF クーポンが貰える ため、認定試験も安く受けることができます。
私は、KCSA 認定試験 とのバンドルプランで購入しましたが、通常 645 USD のところ 451.5 USD で購入できました。（3 万円程度安くなる）
⭐️ 必ず受講 ⭐️
以下のコースを 2〜3 周反復しておくと確実です。
時間があれば受講する
Killer Coda
時間があれば受講することをお勧めしますが、個人的には KodeKloud を反復する方が有意義だと感じました。
The Linux Foundation
こちらは Cilium の基礎が無料で学べます。
出題範囲と試験対策
本題ですが CKS の出題範囲は以下の通りです。
| Domains & Competencies | Score |
|---|---|
| Cluster Setup | 15% |
| Cluster Hardening | 15% |
| System Hardening | 10% |
| Minimize Microservice Vulnerabilities | 20% |
| Supply Chain Security | 20% |
| Monitoring, Logging and Runtime Security | 20% |
一応、公式的に出題範囲を提示してくれていますが、かなり抽象的なので、具体的にどのような対策や何を重点的にキャッチアップしておけば良いかが分かりずらいと感じました。
個人的に頻出されると感じた内容、特に重点的に理解しておいた方が良い領域についてまとめます。合わせて、重点的に読んでおいた方が良いドキュメントも載せておきます。
- CKA / CKAD で問われる内容については書いていません（知っている前提で CKS にフォーカスします）
- 頻出されると感じた内容に関しては ⭐️ を付けます
- 必ず試験に出題される と言っても過言でないものに関しては 💡 を付けます
大まかに、公式の出題範囲（ドメイン）に合わせて振り分けているつもりですが、重複している部分もあります。前提 ⭐️ や 💡 に限らず、ここに書く内容については全て網羅しておくと安心です。
本番試験中にアクセス可能なドキュメントについては以下でまとまっています。
Cluster Setup：15%
- Use Network security policies to restrict cluster level access
- Use CIS benchmark to review the security configuration of Kubernetes components (etcd, kubelet, kubedns, kubeapi)
- Properly set up Ingress with TLS
- Protect node metadata and endpoints
- Verify platform binaries before deploying
クラスタの初期構築・再構成・証明書管理に関する問題。
⭐️ kubeadm Reconfiguring
kubeadm で構築済みクラスタの設定を再構成する操作。特に kubeletConfiguration を変更し、kubelet の挙動（例：認証・cgroup・ログ・セキュリティ設定）を更新する手順が問われる。
例えば、以下の方法を用いることで、ワーカーノードが複数起動している場面では一発で設定内容を伝搬・反映することができる。
### ConfigMap で定義されている kubelet の設定を編集することで設定を変更
$ kubectl edit configmap kubelet-config -n kube-system
### kubelet の変更を反映（ConfigMap の変更内容を /var/lib/kubelet/config.yaml へ反映）
$ kubeadm upgrade node phase kubelet-config
⭐️ クラスタアップデート（kubeadm）
kubeadm を使って Kubernetes のバージョンを安全にアップグレードする手順。Control-Plane → Data-Plane の順で更新し、drain・uncordon を適切に実施できることが重要。
問題によってはすでに Control-Plane のアップグレードが完了しており、それに合わせて Data-Plane のアップグレードを実施するケースもある。
証明書の発行・管理
CertificateSigningRequest を作成し、承認・署名してクライアント証明書を発行する流れ。ユーザやノード認証に用いられる TLS ベースの認証管理が対象。
試験では証明書の CN, Issuer, Subject 等を確認しなければ解けない問題も出題されるので openssl コマンドの利用方法は理解しておく必要がある。
### CSR のフィールドを確認
$ openssl req -in /path/to/hoge.csr -noout -text
### X.509 証明書のフィールドを確認
$ openssl x509 -noout -text -in /path/to/hoge.crt
Bootstrap Token
新しいノードをクラスタへ参加させるための一時的な認証トークン。kubeadm join 時に使用され、トークンの作成・確認・失効管理が問われる。
### 特定のユーザを指定してコンテキストを切り替える
$ export SA_TOKEN=$(cat john-secret.txt)
$ kubectl config set-credentials john --token=$SA_TOKEN
$ kubectl config set-context john-context --cluster=kubernetes --namespace=default --user=john
$ kubectl config use-context john-context
⭐️ Ingress TLS 証明書
Ingress に TLS 証明書を設定し、HTTPS 通信を有効化する方法。Secret に証明書を格納し、Ingress リソースへ関連付ける構成。
試験ではすでに証明書自体が Secret リソースとして準備されていることが多いので、それを利用して Ingress リソースを作成する。
基本的に HTTP を HTTPS にリダイレクトすることが要求されるため、nginx.ingress.kubernetes.io/ssl-redirect: "true" の設定は忘れないようにする。
### -k をつけるこで Self-Signed Certificate の場合でも疎通確認が可能
$ curl -v https://example.com
Cluster Hardening：15%
- Use Role Based Access Controls to minimize exposure
- Exercise caution in using service accounts e.g. disable defaults, minimize permissions on newly created ones
- Restrict access to Kubernetes API
- Upgrade Kubernetes to avoid vulnerabilities
API Server や Control-Plane の防御強化に関する問題。
⭐️ Admission Configuration
API Server に Admission Controller を設定し、リソース作成時にポリシ検証を行う仕組み。
Admission Controller（Kubernetes Admission Webhook）に関しては以下のブログでも紹介しています。
ポリシファイルを kube-apiserver.yaml に設定した上で、関連ファイルまたはディレクトリを利用するたの Volume マウントが必要になるケースが一般的。
spec:
containers:
- command:
- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
- --admission-control-config-file=/etc/admission-controllers/admission-configuration.yaml
volumeMounts:
- name: admission-controllers
mountPath: /etc/admission-controllers
readOnly: true
volumes:
- name: admission-controllers
hostPath:
path: /root/CKS/ImagePolicy/
type: DirectoryOrCreate
ImagePolicyWebhook
外部サービスに問い合わせて、イメージの使用可否を判定する仕組み。
PodSecurity
Pod がセキュリティ基準を満たしているかを Namespace 単位で強制する機能。
⭐️ Pod Security Policy / Pod Security Admission
Pod に許可される権限（例：特権コンテナ・hostPath・特定 Capability）を制限する仕組み。現在は Pod Security Admission（PSA）と Pod Security Standard（PSS）が中心。
以下のモードとレベルで制御する。
- モード：違反した Pod をどう扱うかを制御
| モード | 挙動 |
|---|---|
enforce |
違反 Pod の作成が拒否される |
audit |
違反 Pod の作成は許可されるが監査ログに記録する |
warn |
違反 Pod の作成は許可されるが警告メッセージが表示される |
- レベル：何を危険とみなすか（どこまで制限するか）を制御
| レベル | 何を制御するか | 代表例 |
|---|---|---|
privileged |
ほぼ制限なし | privileged Pod, hostPath, hostNetwork, hostNamespaces |
baseline |
最低限の安全性 | 特権昇格防止、危険 Capability 制限 |
restricted |
非常に厳格 | 非 root 強制、seccomp 必須、capabilities 全禁止 |
試験では PSS を名前空間に設定した上で、違反しているワークロードを修正する問題が中心。
⭐️ Audit Log Policy
API Server の操作ログをどのレベルで記録するかを定義するポリシ。誰が何を実行したかを監査できるようにする。
Audit Log Policy の書き方は重点的に理解しておく。
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
### Secret リソースに関する監査ログを Metadata レベルで記録
- level: Metadata
resources:
- group: ""
resources: ["secrets"]
### "system:nodes" ユーザグループに関連する監査ログを RequestResponse レベルで記録
- level: RequestResponse
userGroups: ["system:nodes"]
### それ以外は何も記録しない
- level: None
試験では、ポリシファイルを API Server にロードするところまで出題される可能性がある。
spec:
containers:
- command:
- --audit-policy-file=/etc/kubernetes/cluster-policy.yaml
- --audit-log-path=/var/log/cluster-audit.log
- --audit-log-maxage=10 ### ログの最大保存日数
- --audit-log-maxbackup=3 ### ログの最大保存数
- --audit-log-maxsize=10 ### ログの最大サイズ
volumeMounts:
- name: audit-policy
mountPath: /etc/kubernetes/cluster-policy.yaml
readOnly: true
- name: varlog
mountPath: /var/log
readOnly: false
volumes:
- name: audit-policy
hostPath:
path: /etc/kubernetes/cluster-policy.yaml
type: File
- name: varlog
hostPath:
path: /var/log
type: Directory
ポリシファイルを更新した場合は、以下の手順でリロードできる。
### ログファイルを空にした上で kube-apiserver を再起動する
$ cd /etc/kubernetes/manifests/
$ mv kube-apiserver.yaml ..
$ echo > /etc/kubernetes/audit/logs/audit.log
$ mv ../kube-apiserver.yaml .
⭐️ CIS Kubernetes Benchmark（kube-bench）
CIS Benchmark に基づき、クラスタ設定がセキュリティ基準を満たしているかを検査するツール。Control-Plane では etcd や kube-apiserver が、Data-Plane では kubelet や kube-proxy の設定不備が修正対象になっていることが多い。
$ kube-bench --benchmark [KUBE_BENCH_VERSION] --config-dir /opt/kube-bench/cfg run --targets master
[FAIL] 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (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)
$ kube-bench --benchmark [KUBE_BENCH_VERSION] --config-dir /opt/kube-bench/cfg run --targets node
[FAIL] 4.1.1 Ensure that the kubelet service file permissions are set to 600 or more restrictive (Automated)
[FAIL] 4.1.9 If the kubelet config.yaml configuration file is being used validate permissions set to 600 or more restrictive (Automated)
OPA Gatekeeper
Open Policy Agent（OPA）を用いて、独自ポリシを Kubernetes に適用する仕組み。特定ラベルの強制といったガバナンスの適用が可能。ConstraintTemplate（CRD）と Constraint というカスタムリソースを定義することで、条件を満たした場合に特定のアクションを実行することができる。
This lecture is work in progress. This topic is for informational purposes only and is not part of the CKS exam curriculum. We will be sure to send out an announcement once it’s ready.
一部では CKS 試験の対象では無い とされているが、実際に Killer Shell でも出題されたので本番試験でも問われる可能性はある。
OPA によるポリシ制御に関しては以下のブログでも紹介しています。
Service Account Token Secret
ServiceAccount に自動生成されるトークン Secret の仕組み。 トークンの扱い・自動マウント制御が問われる。
### Service Account Token Secret
apiVersion: v1
kind: Secret
metadata:
name: dashboard-admin-secret
annotations:
kubernetes.io/service-account.name: "dashboard-admin"
namespace: kubernetes-dashboard
type: kubernetes.io/service-account-token
⭐️ Projected Volume（ServiceAccountToken）
短命トークンを Pod に安全にマウントする仕組みで、従来の長期トークンより安全性が高いとされている。
automountServiceAccountToken: false は Pod ではなく ServiceAccount で設定する方が確実。
apiVersion: v1
kind: ServiceAccount
metadata:
name: bot-sa
namespace: automated
automountServiceAccountToken: false ### 自動マウント（トークン発行）の無効化
spec:
template:
spec:
serviceAccountName: bot-sa ### 追加
containers:
- name: sweeper
image: busybox:1.36
command: ["sleep", "3600"]
volumeMounts: ### 追加
- name: sa-token
mountPath: /var/run/secrets/tokens
readOnly: true
volumes: ### 追加
- name: sa-token
projected:
sources:
- serviceAccountToken:
path: bot-token
expirationSeconds: 3600
System Hardening：10%
- Minimize host OS footprint (reduce attack surface)
- Using least-privilege identity and access management
- Minimize external access to the network
- Appropriately use kernel hardening tools such as AppArmor, seccomp
ノード・OS・ランタイムレベルの強化に関する問題。
⭐️ Docker Security
Docker Daemon の設定やソケット管理といったコンテナランタイム自体のセキュリティ強化に関する内容。
特に頻出される問題となっており、TCP のソケットリッスンの停止や root 実行に切り替える方法について問われることが多い。
daemon.json や Systemd の設定ファイル（/etc/systemd/system/docker.service.d/override.conf）を直接編集することで設定を変更しなければならないものがあり、それらを理解しておく必要がある。
### TCP を無効化
$ sudo vim /etc/docker/daemon.json
{
"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"] ### tcp://0.0.0.0:2375 を消す
}
### docker グループから developer ユーザを外す
$ sudo gpasswd -d develop docker
### SocketGroup を root に変更
$ sudo chown root:root /var/run/docker.sock
$ sudo systemctl edit docker.socket
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --group=root ### --group=root を追加
💡 SecurityContext
Pod / Container にセキュリティ制御を適用する設定。
SecurityContext 関連の問題は 必ず出題される と言っても過言では無いほど毎度登場してくる。
- Seccomp：使用可能な system call を制限
- AppArmor：ファイルやシステムアクセスを制限
- Linux Capabilities：root 権限を細分化し最小権限化
AppArmor Profile や Seccomp Profile 自体はあらかじめ用意されていることが多い印象だが、ドキュメントを見て一から書けるようになっておいた方が確実。
RuntimeClass / Sandbox（Kata / gVisor）
コンテナを軽量 VM やサンドボックス環境で実行する仕組みで、ランタイムレベルで分離を強化するために利用される。
試験では RuntimeClass を作成して、それを Pod に適用する問題をよく見かけた。
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: gvisor
handler: runsc ### 対応する CRI を定義
Minimize Microservice Vulnerabilities：20%
- Use appropriate pod security standards
- Manage Kubernetes secrets
- Understand and implement isolation techniques (multi-tenancy, sandboxed containers, etc.)
- Implement Pod-to-Pod encryption (Cilium, Istio)
アプリケーション・Pod レベルの脆弱性最小化に関する問題。
💡 Network Policy
Pod 間通信を L3 / L4 レベルで制御する仕組み。デフォルトは Deny で、ホワイトリスト形式で許可する通信先を指定するのが基本。通信したいものは全て追加する必要があり、それ以外は拒否されるので要注意。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-traffic-to-products
namespace: products
spec:
podSelector:
matchLabels:
app: web-app
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector: ### 指定した Namespace からのトラフィックを許可（注意：これを指定しないと podSelector は NS products に限定される）
matchLabels:
kubernetes.io/metadata.name: database
podSelector: ### 指定した名前空間にある特定の Pod からのトラフィックを許可
matchLabels:
app: database
- namespaceSelector: ### 指定した Namespace からのトラフィックを許可
matchLabels:
kubernetes.io/metadata.name: payment
Network Policy 適用後の確認は ping でなく curl や wget でやる。（ICMP は別の設定を入れないと応答してしまうので注意）
### 通信が拒否されていることを確認
$ kubectl exec [POD_NAME] -- curl -m 3 [DESTINATION_IP]:[DESTINATION_PORT]
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
curl: (28) Connection timed out after 3002 milliseconds
command terminated with exit code 28
問題によっては Ingress / Egress のどちらでも実現可能なものが出てくるが、文脈から Network Policy が簡素化される構成方法を見極めることが重要。
例えば、以下のような文言がある場合、ホワイトリスト形式をデフォルトとしている Network Policy では Ingress ポリシを書く。（Egress ポリシは複雑化する、または抜け漏れる可能性がある。）
Blocks all other ingress traffic to the frontend pods
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: backend
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
NetworkPolicy または後述する CiliumNetworkPolicy のいずれかは 必ず出題される と言っても過言ではない。
⭐️ Cilium（L3 Policy / L4 Policy）
eBPF を活用した高度なネットワークポリシ制御が可能で、NetworkPolicy よりも詳細なトラフィック制御が可能。
一方、CiliumNetworkPolicy のドキュメントは読みやすいとは言えず、本番試験で検索していると大幅なタイムロスになるので、どのフィールドで何が制御できるのかはあらかた押さえておく。（ドキュメントを見なくても書けるようになっている状態がベスト）
spec:
endpointSelector:
matchLabels:
type: database
egress:
- toEndpoints:
- matchLabels:
type: messenger
authentication:
mode: "required" ### Mutual Authentication の有効化
特に CiliumNetworkPolicy の細かな挙動については熟知しておく必要がある。
以下のパターン 1 と 2 は似ているが挙動が違う。
### パターン 1
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: p1
namespace: team-azure
spec:
endpointSelector:
matchLabels:
role: database
ingressDeny:
- fromEndpoints:
- matchLabels:
role: messenger
### パターン 2
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: p1
namespace: team-azure
spec:
endpointSelector:
matchLabels:
role: messenger
egressDeny:
- toEndpoints:
- matchLabels:
role: database
前者は受信側で拒否する。後者は送信側で送らないようにする。
文中に例えば以下のような表記があった場合、送信側で送らないようにする必要があるので後者を利用しなければならない。
Create a Layer 3 policy named p1 that denies outgoing traffic from Pods with the label role=messenger to Pods with the label role=database.
逆に前者を適用してしまうと減点対象になるので注意。
⭐️ Istio
Service Mesh による mTLS の強制や、Sidecar Injection による暗号化通信の実現について。Service Mesh 自体は複雑な概念で扱うコンポーネントも多いが、試験ではそこまで深堀られる印象はない。
以下を押さえておけば一旦は良い。
- Peer Authentication
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: foo ### クラスタ全体に適用する場合は istio-system を指定
spec:
mtls:
mode: STRICT ### STRICT モードを特定のネームスペースに強制
- Sidecar Injection
Namespace 単位とワークロード単位の両方で指定できる。
| Resource | Label | Enabled value | Disabled value |
|---|---|---|---|
| Namespace | istio-injection |
enabled |
disabled |
| Pod | sidecar.istio.io/inject |
true |
false |
Resource Quota / Limit Range
ResourceQuota は、Namespace 単位でリソース使用量を制限し、DoS やリソース枯渇を防ぐ。LimitRange はワークロード単位でリソースの最小値と最大値を制限する。
Supply Chain Security：20%
- Minimize base image footprint
- Understand your supply chain (e.g. SBOM, CI/CD, artifact repositories)
- Secure your supply chain (permitted registries, sign and validate artifacts, etc.)
- Perform static analysis of user workloads and container images (e.g. Kubesec, KubeLinter)
イメージ検査・改ざん防止・ビルドパイプラインに関する問題。
⭐️ SBOM 生成（Bom / Trivy）
コンテナイメージに含まれるパッケージ一覧（SBOM）を生成し、脆弱性を可視化する。
以下は回答のイメージ。
### 1. SPDX-JSON SBOM を生成
$ bom generate --image registry.k8s.io/kube-apiserver:v1.31.0 --format json --output /opt/course/1/sbom1.json
### 2. CycloneDX SBOM を生成
$ trivy image registry.k8s.io/kube-controller-manager:v1.31.0 --format cyclonedx --output /opt/course/1/sbom2.json
### 3. SPDX-JSON SBOM をスキャン
$ trivy sbom /opt/course/1/sbom_check.json --format json --output /opt/course/1/sbom_check_result.json
KubeLinter
マニフェストの静的解析ツールで、セキュリティ設定ミスを検出する。
$ kube-linter lint ./vulnerable-deployment.yaml --config /root/kube-linter-config.yaml
Kubesec
マニフェストのセキュリティスコアを評価するツールで、SecurityContext 等の設定不備をチェックする。
$ kubesec scan ./vulnerable-pod.yaml
Monitoring, Logging and Runtime Security：20%
- Perform behavioral analytics to detect malicious activities
- Detect threats within physical infrastructure, apps, networks, data, users and workloads
- Investigate and identify phases of attack and bad actors within the environment
- Ensure immutability of containers at runtime
- Use Kubernetes audit logs to monitor access
実行時監視・侵入検知・監査ログに関する問題。
💡 Falco Rule
システムコールを監視し、不審な動作（例：Shell 起動・特権操作）を検知するルール定義。
必ず出題される と言っても過言では無い問題のうち、Kubernetes とは異なるセキュリティに関する専門的な知識を要する内容（失点しやすい問題）。
Falco Rule は以下のフォーマットで定義される。
- rule: [RULE_NAME]
desc: [RULE_DESCRIPTION]
condition: [CONDITION_1] [CONDITION_2] ... [CONDITION_N]
output: [OUTPUT_MESSAGE]
priority: [PRIORITY]
このうち、特に condition と output を所定の条件または形式で記述する問題が出題される。
### /etc/falco/falco_rules.local.yaml
- rule: Detect Crypto Mining Process Execution
desc: Detect Crypto Mining Process Execution
condition: container and proc.name in (xmrig, minerd, cpuminer)
output: >
MINING_ALERT: %evt.time,%container.name,%proc.name
priority: CRITICAL
この例では、xmrig, minerd, cpuminer というプロセスが実行された場合に、タイムスタンプ、コンテナ名、プロセス名を出力する。
### /etc/falco/falco_rules.local.yaml
- rule: Custom Rule 1
desc: Custom Rule 1
condition: container and fd.name startswith /etc/kubernetes ## fd.name を使用して /etc/kubernetes で始まるすべてのフルパスを検索
output: custom_rule_1 file=%fd.name container=%container.id
priority: WARNING
この例では、/etc/kubernetes で始まるすべてのフルパスを検索し、ファイル名とコンテナ ID を出力する。
具体的なフィールドに関しては以下を参考にすること。
Falo Rule をホットリロードする場合は以下のコマンドが有効。
$ kill -1 $(cat /var/run/falco.pid)
Aqua Security – Tracee
eBPF を用いてランタイムイベントを検知するツール。実行時の不審な挙動や侵入兆候を監視する。
実際の試験では特定のツールを使わなくても、Linux 標準コマンドから任意のプロセスを実行するワークロードを検出することも可能。
例えば、/dev/mem にアクセスしている Pod の Deployment のレプリカ数を 0 にするというタスクがあった場合、lsof や fuser を起点に特定することができる。
### 1. /dev/mem を使っているプロセスを特定
$ lsof /dev/mem
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
app 1234 root mem CHR 1,1 0t0 123 /dev/mem
### 2. PID から「どの Pod か」を特定する
$ cat /proc/1234/cgroup
11:memory:/kubepods/burstable/pod3f1a.../docker-abcdef...
### 3. Pod UID から Pod 名・Namespace を引く
$ kubectl get pods -A -o json | jq -r '.items[] | select(.metadata.uid=="3f1a...") | "\(.metadata.namespace)/\(.metadata.name)"'
default/dev-b-7c8d9f6f6b-abcde
### 4. Pod → Deployment を特定
$ kubectl get pod dev-b-7c8d9f6f6b-abcde -n default -o jsonpath='{.metadata.ownerReferences[0].name}'
### 該当 Deployment のレプリカ数を 0 にする
$ kubectl scale deployment dev-b --replicas=0
また、前述の Falco を用いて以下のように Rule を記述すればリアルタイムログから特定することも可能。
- rule: Detect access to /dev/mem
desc: Detect a container accessing /dev/mem device
condition: evt.type in (open, openat) and fd.name = "/dev/mem" and container.id != host
output: >
Container accessing /dev/mem (user=%user.name command=%proc.cmdline container=%container.name pod=%k8s.pod.name namespace=%k8s.ns.name)
priority: CRITICAL
その他：User / Group 操作コマンド
以下は特定の分野で問われるものではないが、常用するコマンドとして知っておくと良い。
$ id [ユーザ名] ## ユーザの存在（ID）を確認
$ useradd [ユーザ名] / userdel [ユーザ名]
$ passwd [ユーザ名]
$ groupadd [グループ名] / groupdel [グループ名]
$ usermod -s /usr/sbin/nologin [ユーザ名] ## このユーザがシステムにログインできないようにする
$ useradd -d [ホームディレクトリパス] -s [ログインシェルパス] -G [グループ名] -u [UID] [ユーザ名]
おわりに
初めて見る方には非常に難しく感じると思います。自分もそうでした。
ここで紹介している内容については KodeKloud を受講すれば網羅的に学ぶことができます。
本番試験は暗記や小手先の理解では通用しないため、模擬試験は問題を解くことに集中するのではなく、その問題のコアとなる関連知識を体系的に理解するために活用します。生成 AI を活用しつつ認識のずれを無くして徹底的にキャッチアップするように意識すると良いと思います。
CKS では CKA / CKAD の内容も登場します。もし時間があれば CKA / CKAD 取得後、すぐに CKS の勉強を開始するとタイムパフォーマンスが良いかと思います。自分は昨年 11 月に CKA / CKAD を受験しましたが、12 月に予定を詰め込んだため CKS の勉強開始まで 1 ヶ月開けることになりました。Kubernetes の操作に自身があるとは言え、一旦基礎を学び直したことで CKS の本題に入るまで時間が掛かりました。
以下のブログでは Kubernetes 認定試験全般の対策についてまとめています。もしよろしければこちらも参考にしてみてください。