Pass the Linux Foundation Kubernetes Security Specialist CKS Questions and answers with ValidTests

Text Description automatically generated

Text Description automatically generated

Text Description automatically generated

Text Description automatically generated

Text Description automatically generated

Text Description automatically generated

$vim /etc/falco/falco_rules.local.yaml

- rule: Container Drift Detected (open+create)

desc: New executable created in a container due to open+create

condition: >

evt.type in (open,openat,creat) and

evt.is_open_exec=true and

container and

not runc_writing_exec_fifo and

not runc_writing_var_lib_docker and

not user_known_container_drift_activities and

evt.rawres>=0

output: >

%evt.time,%user.uid,%proc.name # Add this/Refer falco documentation

priority: ERROR

$kill -1

Explanation[desk@cli] $ ssh node01[node01@cli] $ vim /etc/falco/falco_rules.yamlsearch for Container Drift Detected & paste in falco_rules.local.yaml[node01@cli] $ vim /etc/falco/falco_rules.local.yaml

- rule: Container Drift Detected (open+create)

desc: New executable created in a container due to open+create

condition: >

evt.type in (open,openat,creat) and

evt.is_open_exec=true and

container and

not runc_writing_exec_fifo and

not runc_writing_var_lib_docker and

not user_known_container_drift_activities and

evt.rawres>=0

output: >

%evt.time,%user.uid,%proc.name # Add this/Refer falco documentation

priority: ERROR

[node01@cli] $ vim /etc/falco/falco.yaml

FROM debian:latest

MAINTAINER k@bogotobogo.com

# 1 - RUN

RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -yq apt-utils

RUN DEBIAN_FRONTEND=noninteractive apt-get install -yq htop

RUN apt-get clean

# 2 - CMD

#CMD ["htop"]

#CMD ["ls", "-l"]

# 3 - WORKDIR and ENV

WORKDIR /root

ENV DZ version1

$ docker image build -t bogodevops/demo .

Sending build context to Docker daemon 3.072kB

Step 1/7 : FROM debian:latest

---> be2868bebaba

Step 2/7 : MAINTAINER k@bogotobogo.com

---> Using cache

---> e2eef476b3fd

Step 3/7 : RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -yq apt-utils

---> Using cache

---> 32fd044c1356

Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive apt-get install -yq htop

---> Using cache

---> 0a5b514a209e

Step 5/7 : RUN apt-get clean

---> Using cache

---> 5d1578a47c17

Step 6/7 : WORKDIR /root

---> Using cache

---> 6b1c70e87675

Step 7/7 : ENV DZ version1

---> Using cache

---> cd195168c5c7

Successfully built cd195168c5c7

Successfully tagged bogodevops/demo:latest

Below is the CKS exam style “do-this-exactly” runbook for Q3. It includes the minimal discovery commands (so you don’t guess filenames), then the exact lines/blocks to set.

QUESTION 3 – ImagePolicyWebhook (Validating Admission) – Exam Steps

0) SSH + root

ssh cks000002

sudo -i

1) Identify the provided config files (no guessing)

ls -la /etc/kubernetes/bouncer

You are looking for files typically named like:

admission_configuration.yaml (AdmissionConfiguration)

imagepolicywebhook.yaml (ImagePolicyWebhookConfiguration) OR the ImagePolicyWebhook config embedded inside the AdmissionConfiguration

kubeconfig (webhook kubeconfig)

If unsure which is which, quick peek:

grep -R "ImagePolicyWebhook" -n /etc/kubernetes/bouncer

grep -R "AdmissionConfiguration" -n /etc/kubernetes/bouncer

grep -R "kubeconfig" -n /etc/kubernetes/bouncer

PART A — Reconfigure API Server to enable required admission plugin(s)

2) Edit API server static pod manifest

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

2.1 Enable the admission plugin ImagePolicyWebhook

Find the line starting with:

- --enable-admission-plugins=

Ensure ImagePolicyWebhook is included in that comma list.

Example (your list may differ; just add ImagePolicyWebhook):

- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook

If the flag does not exist, add one line under command::

- --enable-admission-plugins=ImagePolicyWebhook

2.2 Point API server to the provided AdmissionConfiguration

In the same file, ensure this flag exists (use the file in /etc/kubernetes/bouncer that contains AdmissionConfiguration):

- --admission-control-config-file=/etc/kubernetes/bouncer/admission_configuration.yaml

If your file is named differently, use the real filename you found in step 1, but keep the flag name exactly --admission-control-config-file.

Save/exit:

wq

Static pod will restart automatically (kubelet watches the manifest).

Optional quick watch:

docker ps | grep kube-apiserver

# or:

crictl ps | grep kube-apiserver

PART B — Configure ImagePolicyWebhook to deny images on backend failure

3) Edit the ImagePolicyWebhook config

One of these is true on your cluster:

Option 1 (most common in these tasks): ImagePolicyWebhook config is a standalone file

Edit the file in /etc/kubernetes/bouncer that contains kind: ImagePolicyWebhookConfiguration:

grep -R "kind: ImagePolicyWebhookConfiguration" -n /etc/kubernetes/bouncer

vi /etc/kubernetes/bouncer/.yaml

Set (or ensure) exactly:

defaultAllow: false

Option 2: ImagePolicyWebhook config is embedded inside AdmissionConfiguration

Edit the AdmissionConfiguration file:

vi /etc/kubernetes/bouncer/admission_configuration.yaml

Find the plugin section for ImagePolicyWebhook and ensure the config includes:

defaultAllow: false

✅ Save/exit:

wq

PART C — Point backend configuration to https://smooth-yak.local/review

4) Edit the webhook kubeconfig to use the scanner endpoint

Find the kubeconfig file referenced by the ImagePolicyWebhook config.

Search for kubeConfigFile:

grep -R "kubeConfigFile" -n /etc/kubernetes/bouncer

Open that kubeconfig path (example name below; yours may differ):

vi /etc/kubernetes/bouncer/kubeconfig

In kubeconfig, set the cluster server exactly:

clusters:

- cluster:

server: https://smooth-yak.local/review

✅ Save/exit:

wq

PART D — Restart effect (make sure API server picks up config)

Because you already edited /etc/kubernetes/manifests/kube-apiserver.yaml, the API server restarted.

To be safe (and fast), force a restart by “touching” the manifest (no content change needed):

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

PART E — Test: apply vulnerable workload and confirm it is denied

5) Use admin kubeconfig (because old kubectl config may break)

export KUBECONFIG=/etc/kubernetes/admin.conf

kubectl get nodes

6) Deploy the test resource (should be DENIED)

kubectl apply -f /home/candidate/vulnerable.yaml

Expected: admission error/denied message.

If it already exists:

kubectl delete -f /home/candidate/vulnerable.yaml

kubectl apply -f /home/candidate/vulnerable.yaml

PART F — Verify the scanner was called (log check)

7) Check scanner access log

tail -n 50 /var/log/nginx/access_log

You should see requests hitting /review.

Quick “what to check if it doesn’t deny”

Run these in order:

Confirm API server flags:

grep -n "enable-admission-plugins" /etc/kubernetes/manifests/kube-apiserver.yaml

grep -n "admission-control-config-file" /etc/kubernetes/manifests/kube-apiserver.yaml

Confirm deny-on-failure:

grep -R "defaultAllow" -n /etc/kubernetes/bouncer

Must show:

defaultAllow: false

Confirm endpoint:

grep -R "server: https://smooth-yak.local/review " -n /etc/kubernetes/bouncer

API server logs (docker runtime):

docker ps | grep kube-apiserver

docker logs $(docker ps -q --filter name=kube-apiserver) --tail 80

If you paste the output of:

ls -ლა /etc/kubernetes/bouncer

grep -R "kind: AdmissionConfiguration" -n /etc/kubernetes/bouncer

grep -R "ImagePolicyWebhook" -n /etc/kubernetes/bouncer

Install the Runtime Class for gVisor

{ # Step 1: Install a RuntimeClass

cat <

apiVersion: node.k8s.io/v1beta1

kind: RuntimeClass

metadata:

name: gvisor

handler: runsc

EOF

}

Create a Pod with the gVisor Runtime Class

{ # Step 2: Create a pod

cat <

apiVersion: v1

kind: Pod

metadata:

name: nginx-gvisor

spec:

runtimeClassName: gvisor

containers:

- name: nginx

image: nginx

EOF

}

Verify that the Pod is running

{ # Step 3: Get the pod

kubectl get pod nginx-gvisor -o wide

}

1) Connect to the correct host

ssh cks000036

sudo -i

export KUBECONFIG=/etc/kubernetes/admin.conf

2) Confirm the failing Pods + see the PSA error (fast)

kubectl -n confidential get deploy

kubectl -n confidential get pods

kubectl -n confidential describe deploy | sed -n '/Events/,$p'

(You’ll usually see “violates PodSecurity ‘restricted’ …” with the exact missing fields.)

3) Edit the provided manifest

vi /home/candidate/nginx-unprivileged.yaml

You must ensure the Pod template becomes compliant. Add/ensure the following exact blocks:

4) Add Pod-level securityContext (under spec.template.spec)

Find:

spec:

template:

spec:

Add this block under it (or merge if securityContext: already exists):

securityContext:

runAsNonRoot: true

runAsUser: 65535

seccompProfile:

type: RuntimeDefault

5) Add Container-level securityContext (under the nginx container)

Find:

containers:

- name: ...

image: ...

Under that container, add (or adjust) this exact block:

securityContext:

allowPrivilegeEscalation: false

readOnlyRootFilesystem: true

capabilities:

drop:

- ALL

If there are multiple containers, apply the same container securityContext to each one.

Save and exit:

wq

6) Apply the manifest to the confidential namespace

kubectl -n confidential apply -f /home/candidate/nginx-unprivileged.yaml

Wait rollout:

kubectl -n confidential rollout status deployment/

If you don’t know the deployment name from the file, list:

kubectl -n confidential get deploy

7) Verify Pods are running

kubectl -n confidential get pods -o wide

If still failing, show the exact PSA violation (this tells you what else to fix):

kubectl -n confidential describe pod | sed -n '/Events/,$p'

Quick “if it still fails” fixes (common restricted blockers)

Open the manifest again and ensure these are NOT set (or are removed/false):

hostNetwork: true

hostPID: true

hostIPC: true

any hostPort:

privileged: true

capabilities.add:

seccompProfile: Unconfined

runAsUser: 0 or runAsNonRoot: false

Then re-apply.

Minimal compliant result (what the grader expects)

Your Pod template should include:

seccompProfile: RuntimeDefault

runAsNonRoot: true (and a non-root UID like 65535)

container: allowPrivilegeEscalation: false

container: capabilities.drop: [ALL]

container: readOnlyRootFilesystem: true

1) Connect to the correct host

ssh cks000028

sudo -i

2) Use the right kubeconfig (safe in exam)

export KUBECONFIG=/etc/kubernetes/admin.conf

3) Open the provided Deployment manifest

vi /home/candidate/finer-sunbeam/lamp-deployment.yaml

4) Edit ONLY the Pod template security settings (add/modify these fields)

Inside:

spec: -> template: -> spec:

4.1 Set container to run as user 20000

Add (or change) under the container securityContext::

securityContext:

runAsUser: 20000

4.2 Make root filesystem read-only

In the SAME container securityContext: ensure:

readOnlyRootFilesystem: true

4.3 Forbid privilege escalation

In the SAME container securityContext: ensure:

allowPrivilegeEscalation: false

✅ The container section should look like this (example — keep your existing image/ports/etc):

spec:

template:

spec:

containers:

- name:

image:

securityContext:

runAsUser: 20000

readOnlyRootFilesystem: true

allowPrivilegeEscalation: false

If there are multiple containers, apply the same securityContext to each container.

Save and exit:

wq

5) Apply the manifest (updates Deployment -> recreates Pods)

kubectl -n lamp apply -f /home/candidate/finer-sunbeam/lamp-deployment.yaml

6) Wait for rollout

kubectl -n lamp rollout status deployment/lamp-deployment

7) Verify the security settings are live

7.1 Check the Pod is running

kubectl -n lamp get pods -l app=lamp -o wide

(if label differs, just kubectl -n lamp get pods)

7.2 Verify the three fields on a running Pod

Pick the Pod name and run:

POD=$(kubectl -n lamp get pods -o jsonpath='{.items[0].metadata.name}')

kubectl -n lamp get pod $POD -o jsonpath='{.spec.containers[0].securityContext.runAsUser}{"\n"}{.spec.containers[0].securityContext.readOnlyRootFilesystem}{"\n"}{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}'

Expected output:

20000

true

false

If the pod fails after readOnlyRootFilesystem=true

Don’t change the requirement (task demands it). Usually the app needs writable dirs via volumes, but the task doesn’t ask for that—so only adjust if the manifest already has volumes and just needs these securityContext fields.

1) Connect to the correct host

ssh cks000m40

sudo -i

export KUBECONFIG=/etc/kubernetes/admin.conf

2) Verify namespace exists (quick check)

kubectl get ns clever-cactus

3) Verify certificate and key files exist

ls -l /home/candidate/clever-cactus/web.k8s.local.crt

ls -l /home/candidate/clever-cactus/web.k8s.local.key

Both files must exist.

4) Create the TLS Secret (THIS IS THE MAIN TASK)

Create a TLS Secret named clever-cactus in namespace clever-cactus:

kubectl -n clever-cactus create secret tls clever-cactus \

--cert=/home/candidate/clever-cactus/web.k8s.local.crt \

--key=/home/candidate/clever-cactus/web.k8s.local.key

⚠️ Do NOT use apply

⚠️ Do NOT edit the Deployment

5) Verify the Secret

kubectl -n clever-cactus get secret clever-cactus

Expected type:

kubernetes.io/tls

Optional detail check:

kubectl -n clever-cactus describe secret clever-cactus

You should see:

tls.crt

tls.key

6) (Optional) Confirm Pods are running

Since the Deployment is already configured to use the Secret, Pods should now work.

kubectl -n clever-cactus get pods

Below is the CKS / CKA exam-style, exact step-by-step solution for Upgrading a kubeadm worker node.

Follow in order, type exact commands, no extra actions.

QUESTION — Upgrade node compute-0 (EXAM MODE)

1) Connect to the correct host (control plane)

ssh cks000034

sudo -i

export KUBECONFIG=/etc/kubernetes/admin.conf

2) Identify the control plane Kubernetes version

This is the target version for compute-0.

kubectl get nodes

Example output:

NAME STATUS ROLES VERSION

control-plane Ready control-plane v1.27.4

compute-0 Ready v1.26.6

???? Note the control-plane version

Example: v1.27.4

3) Drain the compute node (do NOT modify workloads manually)

kubectl drain compute-0 --ignore-daemonsets --delete-emptydir-data

Wait until drain completes successfully.

4) SSH into the compute node

ssh compute-0

sudo -i

5) Check current kubeadm version on compute node

kubeadm version

6) Upgrade kubeadm to match control plane version

Replace 1.27.4 with the exact control-plane version you observed.

apt-get update

apt-get install -y kubeadm=1.27.4-00

Verify:

kubeadm version

7) Run kubeadm upgrade for the node

kubeadm upgrade node

✅ This updates node-specific configs (NO workloads touched).

8) Upgrade kubelet and kubectl to the same version

apt-get install -y kubelet=1.27.4-00 kubectl=1.27.4-00

9) Restart kubelet

systemctl daemon-reload

systemctl restart kubelet

systemctl status kubelet --no-pager

10) Exit the compute node (IMPORTANT)

exit

11) Uncordon the compute node (back on control plane)

kubectl uncordon compute-0

12) Final verification

kubectl get nodes

Expected:

NAME STATUS VERSION

compute-0 Ready v1.27.4