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

ssh-add ~/.ssh/tempprivate

eval "$(ssh-agent -s)"

cd contrib/terraform/aws

vi terraform.tfvars

terraform init

terraform apply -var-file=credentials.tfvars

ansible-playbook -i ./inventory/hosts ./cluster.yml -e ansible_ssh_user=core -e bootstrap_os=coreos -b --become-user=root --flush-cache -e ansible_user=core

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

Kubernetes auditing provides a security-relevant chronological set of records about a cluster. Kube-apiserver performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what’s recorded and the backends persist the records.

You might want to configure the audit log as part of compliance with the CIS (Center for Internet Security) Kubernetes Benchmark controls.

The audit log can be enabled by default using the following configuration in cluster.yml:

services:

kube-api:

audit_log:

enabled: true

When the audit log is enabled, you should be able to see the default values at /etc/kubernetes/audit-policy.yaml

The log backend writes audit events to a file in JSONlines format. You can configure the log audit backend using the following kube-apiserver flags:

--audit-log-path specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend. - means standard out

--audit-log-maxage defined the maximum number of days to retain old audit log files

--audit-log-maxbackup defines the maximum number of audit log files to retain

--audit-log-maxsize defines the maximum size in megabytes of the audit log file before it gets rotated

If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the hostPath to the location of the policy file and log file, so that audit records are persisted. For example:

--audit-policy-file=/etc/kubernetes/audit-policy.yaml \

--audit-log-path=/var/log/audit.log

$ kubectl get ing -n

NAME HOSTS ADDRESS PORTS AGE

cafe-ingress cafe.com 10.0.2.15 80 25s

$ kubectl describe ing -n

Name: cafe-ingress

Namespace: default

Address: 10.0.2.15

Default backend: default-http-backend:80 (172.17.0.5:8080)

Rules:

Host Path Backends

---- ---- --------

cafe.com

/tea tea-svc:80 ()

/coffee coffee-svc:80 ()

Annotations:

kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{},"name":"cafe-ingress","namespace":"default","selfLink":"/apis/networking/v1/namespaces/default/ingresses/cafe-ingress"},"spec":{"rules":[{"host":"cafe.com","http":{"paths":[{"backend":{"serviceName":"tea-svc","servicePort":80},"path":"/tea"},{"backend":{"serviceName":"coffee-svc","servicePort":80},"path":"/coffee"}]}}]},"status":{"loadBalancer":{"ingress":[{"ip":"169.48.142.110"}]}}}

Events:

Type Reason Age From Message

---- ------ ---- ---- -------

Normal CREATE 1m ingress-nginx-controller Ingress default/cafe-ingress

Normal UPDATE 58s ingress-nginx-controller Ingress default/cafe-ingress

$ kubectl get pods -n

NAME READY STATUS RESTARTS AGE

ingress-nginx-controller-67956bf89d-fv58j 1/1 Running 0 1m

$ kubectl logs -n ingress-nginx-controller-67956bf89d-fv58j

-------------------------------------------------------------------------------

NGINX Ingress controller

Release: 0.14.0

Build: git-734361d

Repository: https://github.com/kubernetes/ingress-nginx

-------------------------------------------------------------------------------

0) Connect to the correct host

ssh cks000023

sudo -i

PART A — Fix ONE prominent Dockerfile security/best-practice issue

1) Open the Dockerfile

vi /home/candidate/subtle-bee/build/Dockerfile

2) Find the “most obvious” security/best-practice problem and modify ONLY THAT ONE instruction

Use / search in vi to quickly find candidates:

Candidate 1 (very common): USER root (or no USER but a USER 0)

Search:

/USER

If you see:

USER root

Change that single instruction to:

USER 65535

(or USER nobody if that exact word is already used in the file—but the task explicitly allows UID 65535, so USER 65535 is safest.)

✅ This is one-instruction change and is a top-tier best practice.

Candidate 2 (very common): FROM <image>:latest

Search:

/FROM

If you see something like:

FROM nginx:latest

Change ONLY that line to a pinned tag (example):

FROM nginx:1.25.5

(Any non-latest pinned version is the point. Don’t add a digest line; just modify the existing FROM line.)

Candidate 3: ADD http://... (remote URL download)

Search:

/ADD

If you see remote URL usage like:

ADD https://example.com/app.tar.gz /app/

Change that single instruction to COPY only if it’s copying local files.

If it’s a remote URL, the more “correct” fix would normally be using curl with verification, but that would require adding instructions (not allowed).

So in this exam constraint, do NOT pick this unless it’s actually a local add like:

ADD . /app

Then change just the word:

COPY . /app

3) Save and exit

wq

⚠️ Don’t run docker build (task forbids building).

PART B — Fix ONE prominent security/best-practice issue in the Deployment manifest

4) Open the manifest

vi /home/candidate/subtle-bee/deployment.yaml

5) Change ONLY ONE existing field that is a clear security issue

Use / search in vi for the usual “bad fields”:

Option 1 (most common): running as root

Search:

/runAsUser

If you see:

runAsUser: 0

Change that one existing field value to:

runAsUser: 65535

✅ This is a single-field change and matches the prompt hint.

Option 2: privileged container

Search:

/privileged

If you see:

privileged: true

Change only that value to:

privileged: false

Option 3: allow privilege escalation

Search:

/allowPrivilegeEscalation

If you see:

allowPrivilegeEscalation: true

Change only that value to:

allowPrivilegeEscalation: false

Option 4: writable root filesystem

Search:

/readOnlyRootFilesystem

If you see:

readOnlyRootFilesystem: false

Change only that value to:

readOnlyRootFilesystem: true

Option 5: image uses :latest

Search:

/image:

If you see:

image: something:latest

Change only that value to a pinned tag, e.g.:

image: something:1.2.3

6) Save and exit

wq

What to pick (fast decision rule)

If you see run as root in either file, that’s usually the highest scoring / most “prominent” security issue.

Dockerfile: USER root → USER 65535

Deployment: runAsUser: 0 → runAsUser: 65535

Those are perfect because you only modify one line/field and it matches the hint.

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