Certified Kubernetes Security Specialist (CKS) #20 フルスケール実技模擬試験: 16 のタスク + 解説

すべての ingress・egress を塞ぐ default deny と DNS egress の許可を併せて適用します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

k apply -f deny.yaml
k -n payments get netpol

解説: 空の podSelector: {} はネームスペースのすべての Pod を対象にします。policyTypes に Ingress と Egress を両方入れてルール本体を空にすると双方向の default deny になります。NetworkPolicy は累積許可なので、2 つ目のポリシーで DNS だけを再び開けます。egress を塞ぐと DNS のクエリまで切れて、すべての通信が名前解決の段階で失敗するのが最もよくある落とし穴なので、53 ポートの許可を落とさないようにします。

control plane ノードで apiserver の static Pod マニフェストを修正します。

ssh cluster1-controlplane
sudo -i

vim /etc/kubernetes/manifests/kube-apiserver.yaml

問題になった 2 つのフラグを次のように置きます。

    - --profiling=false
    - --insecure-port=0

kubelet がマニフェストの変更を検知して apiserver Pod を再生成するまで待った後、もう一度点検します。

crictl ps | grep kube-apiserver
kube-bench run --targets master

解説: --profiling=false はデバッグ用のプロファイリングエンドポイントを閉じて情報の露出を減らすという CIS 推奨で、--insecure-port=0 は認証なしの平文ポートを切るという推奨です。apiserver は static Pod なのでマニフェストを直すと kubelet が自動的に再生成するため、文法エラーで Pod が立たなければ crictl logs で原因を確認します。最新バージョンでは --insecure-port 自体が削除されていることがあるので、点検結果のフラグ名をそのまま踏襲するのが安全です。

過剰な ClusterRoleBinding を消して、最小権限の Role を新たに紐付けます。

k delete clusterrolebinding ci-runner-admin

k -n dev create role ci-reader \
  --verb=get,list,watch \
  --resource=pods,deployments.apps
k -n dev create rolebinding ci-runner-read \
  --role=ci-reader \
  --serviceaccount=dev:ci-runner

権限が意図どおりに狭まったかを検証します。

k -n dev auth can-i list pods --as=system:serviceaccount:dev:ci-runner
k -n dev auth can-i delete pods --as=system:serviceaccount:dev:ci-runner

解説: 最小権限の原則は、主体に必要な動詞・リソース・ネームスペースだけを与えることです。cluster-admin は全クラスターのすべての動作を許可するため、CI ランナーには過剰です。検証では list pods が yes、delete pods が no になって初めて意図どおりに狭まったことになります。ClusterRole はそのままにしてバインディングだけを削除するのが核心で、ClusterRole 自体を消すと他の主体に影響を与えることがあります。

Pod マニフェストに automountServiceAccountToken: false を入れて再生成します。

k -n legacy get pod report -o yaml > report.yaml

spec の下に次のフィールドを追加します。

spec:
  automountServiceAccountToken: false
  containers:
    - name: report
      image: report:1.0

k -n legacy delete pod report
k apply -f report.yaml

マウントが消えたかを確認します。

k -n legacy exec report -- ls /var/run/secrets/kubernetes.io/serviceaccount

解説: automountServiceAccountToken: false は Pod の /var/run/secrets/kubernetes.io/serviceaccount パスにトークンを注入しないようにして、コンテナが奪取されても API サーバーの資格情報が漏れないようにします。このフィールドは Pod spec と ServiceAccount の両方に置けますが、Pod spec 側が優先されます。検証コマンドでディレクトリがないというエラーが出れば正常で、トークンがもうマウントされないという意味です。

ノードでプロファイルを enforce モードでロードします。

ssh node01
sudo -i

apparmor_parser -q /etc/apparmor.d/k8s-deny-write
aa-status | grep k8s-deny-write
exit

Pod に AppArmor プロファイルを指定します。

apiVersion: v1
kind: Pod
metadata:
  name: guarded
  namespace: apps
spec:
  containers:
    - name: web
      image: nginx
      securityContext:
        appArmorProfile:
          type: Localhost
          localhostProfile: k8s-deny-write

k apply -f guarded.yaml
k -n apps get pod guarded

解説: AppArmor プロファイルは コンテナが立つノードにあらかじめロードされていてこそ 適用されるため、apparmor_parser で enforce ロードする段階が抜けると Pod が Blocked 状態で止まります。最新の Kubernetes は securityContext.appArmorProfile フィールドを使い、type: Localhost と localhostProfile にプロファイル名 (ファイルパスではなくプロファイル名) を書きます。旧バージョンの container.apparmor.security.beta.kubernetes.io/<コンテナ> アノテーション方式も同じ効果ですが、試験のバージョンの方式に従います。

securityContext.seccompProfile を RuntimeDefault に置きます。

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-web
  namespace: apps
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: web
      image: nginx

k apply -f seccomp-web.yaml
k -n apps get pod seccomp-web

解説: RuntimeDefault はコンテナランタイム (containerd など) が提供するデフォルトの seccomp プロファイルを適用して、別途のファイルなしで危険なシステムコールを遮断します。Pod レベルの securityContext に置くとすべてのコンテナに継承され、コンテナレベルに置くとそのコンテナだけに適用されます。カスタムプロファイルが必要なら type: Localhost と localhostProfile でノードの /var/lib/kubelet/seccomp/profiles の下の JSON を指しますが、このタスクはデフォルトプロファイルなのでファイルは不要です。

Deployment のコンテナの securityContext を修正します。

k -n apps edit deploy api

コンテナ spec に次を置きます。

        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
            add:
              - NET_BIND_SERVICE

ロールアウトが終わった後、新しい Pod に反映されたかを確認します。

k -n apps rollout status deploy api
k -n apps get pod -l app=api -o jsonpath='{.items[0].spec.containers[0].securityContext}'

解説: capabilities.drop: [ALL] ですべての権限をまず捨て、必要なものだけを add で復活させるのが最小権限のパターンです。NET_BIND_SERVICE は 1024 未満のポートのバインドに必要な権限なので、80 ポートを開く Web サーバーによく残します。allowPrivilegeEscalation: false は setuid バイナリなどでプロセスが親より大きな権限を得ることを防ぎます。Deployment を直すと template が変わり、Pod が新しく立ってから反映されます。

ネームスペースに PSA ラベルを付けます。

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

違反 Pod の生成を試みて拒否されるかを確認します。

k -n restricted run rooty --image=nginx

拒否メッセージを確認した後、標準を通過する Pod で検証します。

apiVersion: v1
kind: Pod
metadata:
  name: compliant
  namespace: restricted
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: web
      image: nginx
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

解説: Pod Security Admission はネームスペースのラベルで動作し、enforce・audit・warn の 3 モードがあります。enforce=restricted は違反 Pod の生成を完全に拒否します。restricted 標準は runAsNonRoot・allowPrivilegeEscalation: false・capabilities.drop: [ALL]・seccompProfile をすべて要求するため、普通の nginx Pod は root で立って拒否されます。ラベルキーが pod-security.kubernetes.io/enforce で正確でないと適用されません。

control plane ノードで暗号化設定ファイルを作ります。

ssh cluster1-controlplane
sudo -i

vim /etc/kubernetes/enc/enc.yaml

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64 でエンコードした 32 バイトのキー>
      - identity: {}

apiserver マニフェストに設定ファイルを連結します。

    - --encryption-provider-config=/etc/kubernetes/enc/enc.yaml

/etc/kubernetes/enc を apiserver コンテナに hostPath ボリュームとしてマウントした後、既存の Secret まで再暗号化します。

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

解説: providers リストの 順序 が重要です。最初の provider が書き込み暗号化に使われ、読み込みは上から試すため、aescbc を先頭に、identity (平文) を後ろに置きます。キーは 32 バイトを base64 でエンコードする必要があり、head -c 32 /dev/urandom | base64 で作ります。設定をオンにしても既存の Secret は自動的に再暗号化されないため、replace で書き直して初めて実際に暗号文になります。

RuntimeClass を作り、Pod から参照します。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: sandboxed
  namespace: apps
spec:
  runtimeClassName: gvisor
  containers:
    - name: web
      image: nginx

k apply -f gvisor.yaml
k -n apps get pod sandboxed

解説: gVisor はシステムコールをユーザー空間で横取りするサンドボックスランタイムなので、コンテナエスケープの危険を大きく減らします。RuntimeClass の handler はノードランタイム (containerd) の設定に登録されたハンドラー名 (runsc) と正確に一致する必要があります。ハンドラーがないノードにスケジュールされると Pod がコンテナ生成の段階で失敗するため、隔離ノードを指す nodeSelector や toleration が併せて必要な場合が多いです。

Deployment のイメージを distroless に置き換えます。

k -n apps set image deploy/legacy-app \
  legacy-app=gcr.io/distroless/nodejs18-debian12

k -n apps rollout status deploy legacy-app

置き換えられたイメージを確認します。

k -n apps get deploy legacy-app -o jsonpath='{.spec.template.spec.containers[0].image}'

解説: distroless イメージはシェル・パッケージマネージャー・不要な OS ユーティリティを除き、アプリの実行に必要なランタイムだけを残して脆弱性の数と攻撃対象領域を大きく減らします。シェルがないので kubectl exec ... -- sh が動作しない点、そして ENTRYPOINT がアプリバイナリに固定される点がデバッグ時の落とし穴です。set image はコンテナ名を正確に指定する必要があり、名前が違うと新しいコンテナが追加されるのではなくコマンドが失敗します。

深刻度をフィルタリングしてスキャンし、結果を保存します。

ssh cluster1-controlplane
sudo -i

trivy image --severity HIGH,CRITICAL nginx:1.21.0 > /opt/trivy-report.txt
cat /opt/trivy-report.txt

脆弱性のないきれいな結果だけを通過させるには終了コードを活用します。

trivy image --severity CRITICAL --exit-code 1 nginx:1.21.0

解説: --severity で等級をカンマでまとめて抽出し、--exit-code 1 は該当等級の脆弱性が 1 つでもあれば 1 で終了して CI パイプラインでデプロイを止めるのに使います。試験では「CRITICAL があるイメージを見つけてその Deployment を安全なイメージに変えよ」のようにスキャンと置き換えをまとめて出すことが多いので、スキャン結果を読んでどのワークロードがそのイメージを使うかを kubectl get で逆追跡する流れも併せて必要です。

公開鍵でイメージ署名を検証します。

cosign verify --key /opt/cosign.pub registry.local/web@sha256:abc...

検証が成功したら、その digest でデプロイします。

k -n apps set image deploy/web web=registry.local/web@sha256:abc...

解説: cosign verify はイメージ署名が与えられた公開鍵で作られたかを確認し、成功すると署名ペイロードを出力して 0 で終了します。タグ (:latest) ではなく digest (@sha256:...) で検証・デプロイして初めて、検証したまさにそのイメージがデプロイされます。タグは後で別のイメージに上書きされることがあり、署名検証の意味がなくなるのが核心的な落とし穴です。クラスター側で未署名のイメージを塞ぐには、Kyverno の verifyImages や sigstore policy-controller で admission の段階で強制します。

イメージタグを検証する Kyverno ClusterPolicy を作ります。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "イメージに明示的なタグが必要で、latest は禁止されます。"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

k apply -f disallow-latest.yaml
k run probe --image=nginx:latest

解説: validationFailureAction: Enforce はポリシー違反のリソースを admission の段階で拒否します (Audit は警告だけを記録)。パターン !*:latest は latest タグを否定マッチで塞ぎ、タグを省略するとランタイムが latest と解釈するため併せて引っかかります。上の検証コマンドの nginx:latest は拒否されて正常です。同じポリシーを OPA/Gatekeeper で書くと ConstraintTemplate と Constraint の 2 リソースに分かれる点が Kyverno との違いです。

ノードの Falco ローカルルールファイルにルールを追加します。

ssh node01
sudo -i

vim /etc/falco/falco_rules.local.yaml

- rule: Shell in container
  desc: コンテナの中でシェルの実行を検知します
  condition: >
    spawned_process and container
    and proc.name in (bash, sh)
  output: >
    Shell spawned in container
    (user=%user.name container=%container.id command=%proc.cmdline)
  priority: WARNING

Falco を再起動し、ルールがロードされたかを確認します。

systemctl restart falco
journalctl -u falco -e | grep "Shell in container"

解説: カスタムルールはメインの falco_rules.yaml ではなく falco_rules.local.yaml に置いてこそ、パッケージのアップグレード時に上書きされません。condition には spawned_process (プロセス生成) と container (コンテナコンテキスト) を AND でまとめ、priority は大文字の等級名を使います。ルール追加後に Falco を再起動してこそ適用され、kubectl exec <pod> -- bash でシェルを立てて Warning ログが出るかで検証します。

control plane ノードで audit policy ファイルを作ります。

ssh cluster1-controlplane
sudo -i

vim /etc/kubernetes/audit/policy.yaml

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources:
          - secrets
  - level: Metadata

apiserver マニフェストに audit フラグを追加し、policy・ログのディレクトリを hostPath でマウントします。

    - --audit-policy-file=/etc/kubernetes/audit/policy.yaml
    - --audit-log-path=/var/log/kubernetes/audit.log
    - --audit-log-maxage=30

crictl ps | grep kube-apiserver
tail -f /var/log/kubernetes/audit.log

解説: audit policy のルールは 上から最初にマッチするルール が適用されるため、より詳しい Secret ルール (RequestResponse) を上に、包括ルール (Metadata) を下に置きます。RequestResponse は要求・応答の本体まで記録して最も詳細で、Metadata は誰が何をしたかだけを残します。policy ファイルとログディレクトリを apiserver コンテナに hostPath ボリュームとしてマウントしないと、コンテナの中でパスを見つけられず apiserver が立たないのがよくある落とし穴です。