Certified Kubernetes Security Specialist (CKS) #20 Full-Length Practice Exam — 16 Tasks with Solutions

Apply a default deny that blocks all ingress and egress together with an allowance for 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

Explanation: An empty podSelector: {} targets every Pod in the namespace. Putting both Ingress and Egress in policyTypes and leaving the rule body empty makes it a bidirectional default deny. NetworkPolicy is additive-allow, so the second policy reopens just DNS. The most common trap is that blocking egress also cuts off DNS lookups, making all communication fail at the name-resolution stage — so never drop the port 53 allowance.

Edit the apiserver static Pod manifest on the control plane node.

ssh cluster1-controlplane
sudo -i

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

Set the two offending flags as follows.

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

Wait for kubelet to detect the manifest change and recreate the apiserver Pod, then check again.

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

Explanation: --profiling=false is the CIS recommendation to close the debugging profiling endpoint and reduce information exposure, and --insecure-port=0 is the recommendation to turn off the unauthenticated plaintext port. The apiserver is a static Pod, so editing the manifest makes kubelet recreate it automatically; if a syntax error keeps the Pod from coming up, check the cause with crictl logs. In recent versions --insecure-port itself may have been removed, so following the exact flag name in the check output is the safe move.

Delete the excessive ClusterRoleBinding and bind a new least-privilege 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

Verify the privileges have been narrowed as intended.

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

Explanation: The principle of least privilege is granting a subject only the verbs, resources, and namespace it needs. cluster-admin permits every action across the entire cluster, which is excessive for a CI runner. In the verification, list pods should return yes and delete pods should return no to confirm the narrowing worked as intended. The key is leaving the ClusterRole alone and removing only the binding — deleting the ClusterRole itself could affect other subjects.

Add automountServiceAccountToken: false to the Pod manifest and recreate it.

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

Add the following field under spec.

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

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

Confirm the mount is gone.

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

Explanation: automountServiceAccountToken: false keeps the token from being injected at the Pod’s /var/run/secrets/kubernetes.io/serviceaccount path, so that even if the container is compromised, the API server credential doesn’t leak. This field can sit on both the Pod spec and the ServiceAccount, and the Pod spec takes precedence. If the verification command errors that the directory doesn’t exist, that is normal — it means the token is no longer mounted.

Load the profile in enforce mode on the node.

ssh node01
sudo -i

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

Assign the AppArmor profile to the Pod.

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

Explanation: An AppArmor profile applies only if it is already loaded on the node where the container lands, so if the apparmor_parser enforce-load step is missing, the Pod gets stuck in a Blocked state. Recent Kubernetes uses the securityContext.appArmorProfile field, with type: Localhost and the profile name (not the file path) in localhostProfile. The older container.apparmor.security.beta.kubernetes.io/<container> annotation approach has the same effect, but follow the exam version’s approach.

Set securityContext.seccompProfile to 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

Explanation: RuntimeDefault applies the default seccomp profile provided by the container runtime (containerd and the like) to block dangerous system calls without a separate file. Put it in the Pod-level securityContext and it is inherited by all containers; put it at the container level and only that container gets it. If you need a custom profile, point type: Localhost and localhostProfile at a JSON file under the node’s /var/lib/kubelet/seccomp/profiles, but this task uses the default profile, so no file is needed.

Edit the Deployment’s container securityContext.

k -n apps edit deploy api

Place the following in the container spec.

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

After the rollout completes, confirm it took effect on the new Pods.

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

Explanation: The pattern of capabilities.drop: [ALL] to first drop every privilege, then adding back only what’s needed with add, is the least-privilege pattern. NET_BIND_SERVICE is the privilege required to bind ports below 1024, so it is commonly kept on a web server that opens port 80. allowPrivilegeEscalation: false blocks a process from gaining more privilege than its parent via setuid binaries and the like. Editing the Deployment changes the template, so it takes effect only once Pods are recreated.

Apply the PSA labels to the namespace.

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

Attempt to create a violating Pod and confirm it is rejected.

k -n restricted run rooty --image=nginx

After confirming the rejection message, verify with a Pod that passes the standard.

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

Explanation: Pod Security Admission works via namespace labels and has three modes: enforce, audit, and warn. enforce=restricted outright rejects the creation of violating Pods. The restricted standard requires all of runAsNonRoot, allowPrivilegeEscalation: false, capabilities.drop: [ALL], and seccompProfile, so a plain nginx Pod is rejected because it runs as root. The label key must be exactly pod-security.kubernetes.io/enforce to take effect.

Create the encryption config file on the control plane node.

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-encoded 32-byte key>
      - identity: {}

Link the config file in the apiserver manifest.

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

After mounting /etc/kubernetes/enc into the apiserver container as a hostPath volume, re-encrypt the existing Secrets too.

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

Explanation: The order of the providers list matters. The first provider is used for write encryption, and reads are tried from the top down, so put aescbc first and identity (plaintext) last. The key must be 32 bytes base64-encoded, generated with head -c 32 /dev/urandom | base64. Turning on the config does not auto-re-encrypt existing Secrets, so you must rewrite them with replace for them to actually become ciphertext.

Create the RuntimeClass and reference it from the 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

Explanation: gVisor is a sandbox runtime that intercepts system calls in user space, greatly reducing the risk of container escape. The RuntimeClass handler must exactly match the handler name (runsc) registered in the node runtime (containerd) config. If it is scheduled onto a node without the handler, the Pod fails at the container-creation stage, so a nodeSelector or toleration pointing at the isolation nodes is often needed alongside it.

Swap the Deployment’s image to distroless.

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

k -n apps rollout status deploy legacy-app

Confirm the swapped image.

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

Explanation: A distroless image drops the shell, package manager, and unnecessary OS utilities, keeping only the runtime needed to run the app, which greatly reduces the number of vulnerabilities and the attack surface. The traps during debugging are that kubectl exec ... -- sh won’t work because there’s no shell, and that the ENTRYPOINT is fixed to the app binary. set image must name the container exactly; if the name is wrong, the command fails rather than adding a new container.

Filter by severity in the scan and save the results.

ssh cluster1-controlplane
sudo -i

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

To pass only clean results with no vulnerabilities, use the exit code.

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

Explanation: --severity narrows results by joining severities with commas, and --exit-code 1 exits with 1 if there is even one vulnerability of those severities, which is used in a CI pipeline to block deployment. The exam often bundles scanning and swapping into “find the image with a CRITICAL and swap its Deployment to a safe image,” so a flow of reading scan results and tracing back which workload uses that image with kubectl get is needed alongside.

Verify the image signature with the public key.

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

If verification succeeds, deploy by that digest.

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

Explanation: cosign verify checks whether the image signature was made with the given public key; on success it prints the signature payload and exits with 0. You must verify and deploy by digest (@sha256:...) rather than a tag (:latest), so that the exact image you verified is the one deployed. The key trap is that a tag can later be overwritten with a different image, which voids the meaning of signature verification. To block unsigned images at the cluster level, enforce it at the admission stage with Kyverno’s verifyImages or the sigstore policy-controller.

Create a Kyverno ClusterPolicy that validates the image tag.

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: "An explicit image tag is required and latest is forbidden."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

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

Explanation: validationFailureAction: Enforce rejects policy-violating resources at the admission stage (Audit only records a warning). The pattern !*:latest blocks the latest tag with a negative match, and since omitting the tag makes the runtime interpret it as latest, that is caught too. The nginx:latest in the verification command above should be rejected to be correct. Writing the same policy with OPA/Gatekeeper splits it into two resources, a ConstraintTemplate and a Constraint — that is the difference from Kyverno.

Add the rule to the node’s Falco local rules file.

ssh node01
sudo -i

vim /etc/falco/falco_rules.local.yaml

- rule: Shell in container
  desc: Detect a shell running inside a container
  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

Restart Falco and confirm the rule loaded.

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

Explanation: A custom rule should go in falco_rules.local.yaml, not the main falco_rules.yaml, so it isn’t overwritten on a package upgrade. The condition ANDs spawned_process (process creation) and container (container context), and priority uses the uppercase severity name. The rule takes effect only after you restart Falco, and you verify by spawning a shell with kubectl exec <pod> -- bash and checking that a Warning log appears.

Create the audit policy file on the control plane node.

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

Add the audit flags to the apiserver manifest and mount the policy and log directories as 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

Explanation: The rules in an audit policy apply by the first rule that matches, from the top, so put the more specific Secret rule (RequestResponse) above and the catch-all rule (Metadata) below. RequestResponse records down to the request and response bodies, making it the most detailed, while Metadata leaves only who did what. A common trap is failing to mount the policy file and log directory into the apiserver container as hostPath volumes — the container then can’t find the paths and the apiserver won’t come up.