2024.06.26 セキュリティー

CKSとは｜Kubernetesセキュリティ認定の受験条件・費用・出題範囲を解説

CKS（Certified Kubernetes Security Specialist）は、Linux Foundationが実施するKubernetesセキュリティの実技認定です。選択式の問題はなく、実際に動いているクラスタへコマンドラインで手を入れて課題を解きます。本記事のCKSはこのKubernetes認定資格を指します。受験条件と費用、合格ライン、CNCFが公開する6ドメインの配点、出題範囲に直結するツールの最小構成を、公式カリキュラムとKubernetes公式ドキュメントに沿って整理します。学習教材に残る旧記法をそのまま覚えると失点する箇所にも触れます。

まとめ

  • CKSは有効なCKA認定の保持が受験の前提条件です。CKAを持たない状態では申し込めません。
  • 費用は英語版が445ドル、LPI-Japanが扱う日本語版CKS-JPが69,000円です。試験時間はいずれも2時間、CKSの認定有効期限は2年です。英語版の合格ラインは67%が公表されています。
  • 出題は6ドメインで、Minimize Microservice Vulnerabilities・Supply Chain Security・Monitoring, Logging and Runtime Securityの3つが各20%を占めます。ここで6割が決まります。
  • 試験環境のKubernetesは英語版がv1.35、LPI-Japanが公表するCKS-JPがv1.26です。PodSecurityPolicyとCronJobのbatch/v1beta1はどちらの環境でも通用しませんが、AppArmorの正解となる記法は環境によって逆になります。
  • 試験中に参照できるのはkubernetes.ioを含む8つのドメインだけです。TrivyやOPA Gatekeeperの公式ドキュメントは参照できないため、これらはコマンドを手に覚えさせておく必要があります。

CKSが証明する範囲とKubernetes認定群での位置づけ

CKAを前提資格に置く理由

CKSはクラスタを安全に構成・運用する能力を測る試験です。Linux Foundationは受験の前提として、有効なCKA（Certified Kubernetes Administrator）認定の保持を必須としています。CKAが失効していると申し込みが通りません。

この前提は形式的なものではありません。CKSの課題は「NetworkPolicyを書いて特定の通信だけ通す」「監査ログのポリシーを設定する」といった形で出題され、Deployment・Service・RBACの操作は説明抜きで前提にされます。kubectlでリソースを追う段階で時間を使えば、2時間では終わりません。Kubernetesの構造に不安が残るなら、先にKubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説で全体像を押さえてからCKAに進む順序が確実です。

KCSA・CKA・CKADとの役割分担

Kubernetes関連の認定は複数あり、CKSはこの中で最上位に位置します。KCSA（Kubernetes and Cloud Native Security Associate）は選択式でセキュリティの概念を問う入門資格で、実技はありません。CKAはクラスタ管理、CKADはアプリケーション開発が対象です。

セキュリティ担当としての実力を対外的に示すなら、KCSAではなくCKSを狙う価値があります。KCSAは前提資格が不要なぶん、クラスタを実際に触れることの証明にはならないためです。

受験条件・費用・合格ラインの実数値

英語版CKSと日本語版CKS-JPの条件差

CKSは英語版と、LPI-Japanが取り扱う日本語版CKS-JPの2系統があります。前提資格は系統ごとに対応しており、CKS-JPを受けるにはCKA-JPの有効な認定が必要です。

項目 CKS（英語版） CKS-JP（LPI-Japan）
受験料 445ドル 69,000円
試験時間 2時間 120分
前提資格 有効なCKA 有効なCKA-JP
認定の有効期限 2年 2年
試験環境のバージョン Kubernetes v1.35 Kubernetes v1.26

見落とされやすいのが最終行です。LPI-Japanが公表するCKS-JPの試験環境はKubernetes v1.26で、英語版のv1.35とは9マイナーバージョン離れています。この差は後述するAppArmorの指定方法など記法の正解そのものを左右するので、どちらを受けるか決めてから教材を選んでください。公表値は改訂が遅れることもあるため、申込時に最新の記載を確認しておくと安全です。

日本語で問題文を読めることを取るならCKS-JP、公式教材や演習環境が英語前提であることに合わせるなら英語版という選び方になります。

合格ライン67%と有効期限2年の扱い

英語版の合格に必要なスコアは67%です。CKAとCKADの66%よりわずかに高く設定されています。

認定の有効期限は2年です。ここで混同しやすいのが、2024年4月1日より前の取得に3年間の有効期限が認められる経過措置で、これはCKAとCKADだけが対象です。CKSは取得時期にかかわらず一律2年なので、前提資格のCKAより先にCKS側の期限が来る場合があります。

受験券の購入後は12か月以内にスケジュールする必要があり、受験機会は2回、つまり初回で不合格でも1度は再挑戦できます。あわせてkiller.shの試験シミュレータが2セッション付属し、1セッションあたり36時間アクセスでき、17問が出題されます。

出題6ドメインと配点の内訳

配点はCNCFの公式カリキュラムで公開されています。上位3ドメインで60%を占めるため、時間配分はここに寄せるのが合理的です。

ドメイン 配点 中心となる題材
Minimize Microservice Vulnerabilities 20% Pod Security Standards、Secrets、Cilium
Supply Chain Security 20% SBOM、署名検証、Trivy、Kubesec
Monitoring, Logging and Runtime Security 20% Falco、監査ログ
Cluster Setup 15% NetworkPolicy、CIS Benchmark、TLS
Cluster Hardening 15% RBAC、ServiceAccount、API制限
System Hardening 10% AppArmor、seccomp、最小権限

Cluster Setupにはこのほか、ノードのメタデータとエンドポイントの保護、配布バイナリの検証も含まれます。NetworkPolicyはPodレベルの通信制御を書けるかがそのまま問われますが、CNIがNetworkPolicyに対応していなければマニフェストを適用しても何も起きません。この前提はKubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断で整理しています。

ドメイン別の頻出ツールと最小構成

クラスタ設定監査のkube-bench

kube-benchは、APIサーバやkubelet、etcdの設定がCIS Benchmarkに沿っているかを検査します。実行するとチェック項目ごとにPASS・FAIL・WARNが並び、FAILには修正すべき設定値が併記されます。最新版は2026年8月5日リリースのv0.16.0です。

# 対象はKubernetesのバージョンから自動判定される
kube-bench

# コントロールプレーンだけに絞る場合
kube-bench run --targets master

# クラスタ内でJobとして実行する場合
kubectl apply -f job.yaml

–targetsに指定できるのはmaster、controlplane、node、etcd、policiesです。指定を省略すると稼働中のKubernetesバージョンから対応するCIS Benchmarkが自動で選ばれます。v0.16.0のマッピングはv1.34までなので、英語版の試験環境v1.35ではv1.32からv1.34向けのcis-1.12が適用されます。試験では引数なしで走らせ、出力を読む方が速く済みます。

イメージ脆弱性スキャンとサプライチェーン検証

Supply Chain Securityは配点20%で、公式カリキュラムはベースイメージの縮小、SBOMやCI/CDを含む供給経路の把握、許可レジストリの限定と成果物の署名検証、そしてワークロードとイメージの静的解析を挙げています。

脆弱性スキャンの中心はTrivyです。コンテナイメージ、ファイルシステム、IaC設定を対象に既知の脆弱性を検出します。最新版は2026年8月3日リリースのv0.73.0です。

# インストール（Homebrewの場合）
brew install trivy

# HIGH以上だけを表示する
trivy image --severity HIGH,CRITICAL nginx:1.29

# 検出時に終了コード1を返す（CIでの遮断に使う）
trivy image --exit-code 1 --severity CRITICAL nginx:1.29

試験では「脆弱性のあるイメージを使うPodを特定して削除する」形の課題が出ます。全件を眺める時間はないので、–severityで絞り込む使い方に慣れておいてください。KubernetesそのもののCVEが出た場合の影響範囲の読み方は、CVE-2026-31431「Copy Fail」とは？影響範囲と今すぐ行うべきパッチ・緩和策をわかりやすく解説が具体例になります。

静的解析ツールとして公式カリキュラムが名前を挙げているのがKubesecとKubeLinterです。Kubesecはマニフェストを採点し、privileged指定やcapabilitiesの過剰付与を減点として示します。

kubesec scan pod.yaml

注意したいのは更新状況です。直近リリースはv2.14.2で2024年11月、1年半以上止まっており、v1.31以降で追加されたフィールドを評価軸に取り込めていない可能性があります。出題範囲に明記されている以上スキップはできませんが、スコアだけを根拠に安全と判断せず、Pod Security Admissionの判定と併用してください。

実行時検知のFalco

Falcoはシステムコールを監視し、コンテナ内でのシェル起動や機密ファイルの読み取りといった挙動を検知します。最新版は2026年6月11日リリースの0.44.1です。

導入方法は変わりました。公式ドキュメントが推奨方式とするのはFalco Operatorです。Helmも引き続きサポートされ、Helmを使わずマニフェストを直接適用する方法も残っています。いずれの経路でも既定構成はノード全体へ展開するDaemonSetで、カーネルイベントを読むため特権が必要です。

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install --replace falco --namespace falco \
  --create-namespace --set tty=true falcosecurity/falco

試験で問われるのは導入手順より検知ルールの読み書きと出力の解釈です。どのルールがどのイベントに反応したかをログから特定し、条件を足す作業を練習しておくと得点しやすくなります。同じドメインには実行中コンテナの不変性の担保も含まれるため、readOnlyRootFilesystemを有効にしたPodも書けるようにしておいてください。

ポリシー強制のPod Security AdmissionとOPA Gatekeeper

Pod Security Admissionはv1.25で安定版になった標準機能です。Namespaceにラベルを貼るだけで、privileged・baseline・restrictedの3レベルをenforce・audit・warnの3モードで適用できます。

apiVersion: v1
kind: Namespace
metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.35
    pod-security.kubernetes.io/warn: restricted

enforce-versionにはクラスタのマイナーバージョン以下の値しか指定できないため、v1.26環境のCKS-JPで学習する場合はここを読み替えてください。enforceに違反したPodは作成が拒否され、warnは警告のみを返します。まずwarnとauditで影響範囲を確認してからenforceへ切り替える運用が、既存ワークロードを落とさない進め方です。

標準のレベルで表現できない条件、たとえば「特定のラベルが付いていないPodを拒否する」といった組織固有の要件にはOPA Gatekeeperを使います。最新版は2026年7月9日リリースのv3.23.0です。公式カリキュラムはGatekeeperを名指ししていませんが、pod security standardsを実装する定番の手段です。ConstraintTemplateでRegoの判定ロジックを定義し、Constraintで適用対象を指定する2段構成になります。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {"app", "team"}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Missing required labels: %v", [missing])
        }

Pod Security Admissionで足りる要件にGatekeeperを持ち込むと、Regoの記述量とCRDの管理コストだけが増えます。標準機能で表現できるかを先に確かめてください。

最小権限RBACとServiceAccountの絞り込み

Cluster Hardeningは配点15%で、RBACによる権限の最小化、ServiceAccountの慎重な扱い、Kubernetes APIへのアクセス制限、脆弱性を避けるためのバージョン更新が対象です。RBACは対象リソースと動詞を絞ったRoleを作り、RoleBindingで必要な主体にだけ結び付けます。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ServiceAccountで見落としやすいのが既定のトークン自動マウントです。Podが自分のServiceAccountトークンを持つと、侵入された際にそのままAPIサーバへの足がかりになります。使わないなら明示的に切ってください。同じフィールドはPod側のspecにもあり、両方に指定があるときはPod側が優先されます。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: no-api-access
  namespace: default
automountServiceAccountToken: false

APIサーバがどのリソースにどの動詞を許すかという構造を理解していると、権限設計の判断が速くなります。全体像はKubernetes APIとは｜仕組み・リソース・エンドポイント構造とCRD拡張を実例で解説で確認できます。

Secretsの保護とPod間通信の分離

配点20%のMinimize Microservice Vulnerabilitiesは、Pod Security Standardsの適用だけでなく、Secretsの管理、マルチテナンシーやサンドボックスコンテナによる分離、Pod間通信の暗号化までを範囲に含みます。

Secretsは既定でetcdにbase64で格納されるだけなので、保存時の暗号化を有効にするか外部のシークレット管理へ寄せる判断が要ります。分離では、RuntimeClassを使ってgVisorやKata ContainersといったサンドボックスランタイムへPodを割り当てる構成が問われます。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

Pod間の暗号化について、公式カリキュラムはCiliumとIstioを名指ししています。Ciliumの透過的暗号化はCNI層で経路を暗号化し、Istioはサイドカー間の相互TLSで実現します。試験中はどちらの公式ドキュメントも参照できるため、設定項目の丸暗記より、どちらの層で暗号化するかの違いを押さえておく方が実戦的です。

システムコールとファイルアクセスを絞るseccompとAppArmor

seccompとAppArmorは配点10%のSystem Hardeningに属します。カーネルの機能で攻撃面を削る位置づけです。seccompはコンテナが発行できるシステムコールを制限し、RuntimeDefaultを指定すればコンテナランタイムの既定プロファイルが適用されます。

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: nginx:1.29
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

AppArmorはファイルやネットワークへのアクセスをプロファイルで制御します。指定方法はsecurityContext配下のappArmorProfileフィールドで、v1.31で安定版になりました。

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

typeにはLocalhost、RuntimeDefault、Unconfinedを指定できます。Localhostを使う場合、指定した名前のプロファイルがノード側に配置済みであることが前提です。

旧記法のまま覚えると失点する3つの箇所

英語版CKSの試験環境はKubernetes v1.35です。ところがWeb上の学習記事や動画教材には、v1.25以前を前提にした記法が残っており、意識して上書きしないと手が勝手に古い書き方を出します。

AppArmorのannotation指定は使わない。ただしCKS-JPは逆。 v1.30より前はcontainer.apparmor.security.beta.kubernetes.ioというannotationでプロファイルを指定していました。v1.35環境ではsecurityContextのappArmorProfileフィールドが安定版であり、公式ドキュメントも新しいAPIで記述されています。一方、LPI-Japanが公表するCKS-JPの環境はv1.26で、appArmorProfileフィールドがまだ存在しません。日本語版を受けるならannotationの記法が唯一の正解になります。上の設定例をそのまま使えるのは英語版だけだと理解しておいてください。

PodSecurityPolicyは存在しない。 policy/v1beta1のPodSecurityPolicyはv1.25で提供が終了し、admissionコントローラも削除されました。直接の後継APIは用意されておらず、Pod Security Admissionか第三者のadmission webhookへ移行する設計になっています。PSPを前提にした演習問題は現行試験では成立しません。

CronJobのapiVersionはbatch/v1。 batch/v1beta1のCronJobもv1.25で提供が終了しました。移行先のbatch/v1はv1.21から利用できます。kube-benchを定期実行するCronJobを書く場面で、古いapiVersionのままだと適用時点で弾かれます。

試験環境のバージョンは更新されます。学習を始める時点で対象バージョンを確認し、Kubernetes 1.35主要新機能と変更点を徹底解説のような版ごとの変更点で差分を追ってください。

合格までの学習手順と試験中に参照できるドメイン

まず前節の配点上位3ドメインから着手します。ここを固めれば合格ライン67%の大半が埋まります。

次に手を動かす環境を用意します。kubeadmで構築したマルチノードのクラスタが望ましく、マネージドサービスではAPIサーバの起動オプションを直接編集する課題を再現できません。kube-benchのFAIL項目を1つずつ潰していく作業が、そのままCluster SetupとCluster Hardeningの演習になります。

試験直前にkiller.shの2セッションを使います。1回目で時間配分と弱点を把握し、アクセス期間内に解説を読み込んでから、2回目で再現性を確認する流れが効率的です。

見落とされがちなのが、試験中に閲覧できるドメインが限定されている点です。Linux Foundationが許可しているのは次の8つです。

  • Kubernetesドキュメント（kubernetes.io/docs/）
  • Kubernetesブログ（kubernetes.io/blog/）
  • Falcoドキュメント（falco.org/docs/）
  • etcdドキュメント（etcd.io/docs/）
  • Ciliumドキュメント（docs.cilium.io）
  • Istioドキュメント（istio.io）
  • NGINX Ingress Controllerドキュメント（kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/ の配下のみ）
  • bomドキュメント（kubernetes-sigs.github.io/bom/cli-reference/）

この一覧にTrivy、OPA Gatekeeper、Kubesecは入っていません。本記事で扱ったサードパーティ製ツールのうち、試験中にドキュメントを引けるのはFalco・Cilium・Istioの3つだけです。TrivyのフラグやKubesecの実行方法はその場で調べられないため、コマンドの形を手に覚えさせておく必要があります。逆にPod間暗号化の設定はCiliumとIstioの公式ドキュメントを開けるため、丸暗記は不要です。Pod Security AdmissionやRBAC、seccompはkubernetes.io配下なので同様に参照できます。

よくある質問

CKSはCKAを持っていなくても受験できますか？

できません。Linux Foundationは有効なCKA認定の保持をCKS受験の必須条件としています。CKAが失効している場合も申し込めないため、期限を確認してください。

CKSの合格ラインは何%ですか？

英語版のCKSは67%です。CKAとCKADの66%より1ポイント高く設定されています。

CKS認定の有効期限はどれくらいですか？

2年です。2024年4月1日より前の取得に3年間が認められる経過措置はCKAとCKADだけが対象で、CKSは取得時期にかかわらず一律2年です。

CKSの試験時間と受験できる回数は？

試験時間は2時間です。受験券の購入から12か月以内にスケジュールする必要があり、受験機会は2回あります。初回が不合格でも1度は再挑戦できます。

日本語でCKSを受験できますか？

できます。LPI-Japanが日本語版のCKS-JPを提供しており、受験料は69,000円、試験時間は120分、認定の有効期限は2年です。受験にはCKA-JPの有効な認定が必要です。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る