Linux Foundation CKS Certified Kubernetes Security Specialist (CKS) Exam Practice Test

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

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

worker1 $ vim /var/lib/kubelet/config.yaml

anonymous:

enabled: true #Delete this

enabled: false #Replace by this

authorization:

mode: AlwaysAllow #Delete this

mode: Webhook #Replace by this

worker1 $ systemctl restart kubelet.    # To reload kubelet config

ssh to master1

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

- -- authorization-mode=Node,RBAC

master1 $ vim /etc/kubernetes/manifests/etcd.yaml

- --client-cert-auth=true

Explanationssh to worker1

worker1 $ vim /var/lib/kubelet/config.yaml

apiVersion: kubelet.config.k8s.io/v1beta1

authentication:

anonymous:

enabled: true #Delete this

enabled: false #Replace by this

webhook:

cacheTTL: 0s

enabled: true

x509:

clientCAFile: /etc/kubernetes/pki/ca.crt

authorization:

mode: AlwaysAllow #Delete this

mode: Webhook #Replace by this

webhook:

cacheAuthorizedTTL: 0s

cacheUnauthorizedTTL: 0s

cgroupDriver: systemd

clusterDNS:

- 10.96.0.10

clusterDomain: cluster.local

cpuManagerReconcilePeriod: 0s

evictionPressureTransitionPeriod: 0s

fileCheckFrequency: 0s

healthzBindAddress: 127.0.0.1

healthzPort: 10248

httpCheckFrequency: 0s

imageMinimumGCAge: 0s

kind: KubeletConfiguration

logging: {}

nodeStatusReportFrequency: 0s

nodeStatusUpdateFrequency: 0s

resolvConf: /run/systemd/resolve/resolv.conf

rotateCertificates: true

runtimeRequestTimeout: 0s

staticPodPath: /etc/kubernetes/manifests

streamingConnectionIdleTimeout: 0s

syncFrequency: 0s

volumeStatsAggPeriod: 0s

worker1 $ systemctl restart kubelet.    # To reload kubelet config

ssh to master1

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

master1 $ vim /etc/kubernetes/manifests/etcd.yaml

A service account provides an identity for processes that run in a Pod.

When you (a human) access the cluster (for example, using kubectl), you are authenticated by the apiserver as a particular User Account (currently this is usually admin, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).

When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. If you get the raw json or yaml for a pod you have created (for example, kubectl get pods/ -o yaml), you can see the spec.serviceAccountName field has been automatically set.

You can access the API from inside a pod using automatically mounted service account credentials, as described in Accessing the Cluster. The API permissions of the service account depend on the authorization plugin and policy in use.

In version 1.6+, you can opt out of automounting API credentials for a service account by setting automountServiceAccountToken: false on the service account:

apiVersion: v1

kind: ServiceAccount

metadata:

name: build-robot

automountServiceAccountToken: false

In version 1.6+, you can also opt out of automounting API credentials for a particular pod:

apiVersion: v1

kind: Pod

metadata:

name: my-pod

spec:

serviceAccountName: build-robot

automountServiceAccountToken: false

The pod spec takes precedence over the service account if both specify a automountServiceAccountToken value.

Create a PSP that will prevent the creation of privileged pods in the namespace.

$ cat clusterrole-use-privileged.yaml

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

name: use-privileged-psp

rules:

- apiGroups: ['policy']

resources: ['podsecuritypolicies']

verbs: ['use']

resourceNames:

- default-psp

---

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: privileged-role-bind

namespace: psp-test

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

name: use-privileged-psp

subjects:

- kind: ServiceAccount

name: privileged-sa

$ kubectl -n psp-test apply -f clusterrole-use-privileged.yaml

After a few moments, the privileged Pod should be created.

Create a new PodSecurityPolicy named prevent-privileged-policy which prevents the creation of privileged pods.

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

name: example

spec:

privileged: false # Don't allow privileged pods!

# The rest fills in some required fields.

seLinux:

rule: RunAsAny

supplementalGroups:

rule: RunAsAny

runAsUser:

rule: RunAsAny

fsGroup:

rule: RunAsAny

volumes:

- '*'

And create it with kubectl:

kubectl-admin create -f example-psp.yaml

Now, as the unprivileged user, try to create a simple pod:

kubectl-user create -f- <

apiVersion: v1

kind: Pod

metadata:

name: pause

spec:

containers:

- name: pause

image: k8s.gcr.io/pause

EOF

The output is similar to this:

Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []

Create a new ServiceAccount named psp-sa in the namespace default.

$ cat clusterrole-use-privileged.yaml

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

name: use-privileged-psp

rules:

- apiGroups: ['policy']

resources: ['podsecuritypolicies']

verbs: ['use']

resourceNames:

- default-psp

---

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: privileged-role-bind

namespace: psp-test

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

name: use-privileged-psp

subjects:

- kind: ServiceAccount

name: privileged-sa

$ kubectl -n psp-test apply -f clusterrole-use-privileged.yaml

After a few moments, the privileged Pod should be created.

Create a new ClusterRole named prevent-role, which uses the newly created Pod Security Policy prevent-privileged-policy.

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

name: example

spec:

privileged: false # Don't allow privileged pods!

# The rest fills in some required fields.

seLinux:

rule: RunAsAny

supplementalGroups:

rule: RunAsAny

runAsUser:

rule: RunAsAny

fsGroup:

rule: RunAsAny

volumes:

- '*'

And create it with kubectl:

kubectl-admin create -f example-psp.yaml

Now, as the unprivileged user, try to create a simple pod:

kubectl-user create -f- <

apiVersion: v1

kind: Pod

metadata:

name: pause

spec:

containers:

- name: pause

image: k8s.gcr.io/pause

EOF

The output is similar to this:

Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []

Create a new ClusterRoleBinding named prevent-role-binding, which binds the created ClusterRole prevent-role to the created SA psp-sa.

apiVersion: rbac.authorization.k8s.io/v1

# This role binding allows "jane" to read pods in the "default" namespace.

# You need to already have a Role named "pod-reader" in that namespace.

kind: RoleBinding

metadata:

name: read-pods

namespace: default

subjects:

# You can specify more than one "subject"

- kind: User

name: jane # "name" is case sensitive

apiGroup: rbac.authorization.k8s.io

roleRef:

# "roleRef" specifies the binding to a Role / ClusterRole

kind: Role #this must be Role or ClusterRole

name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to

apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: default

name: pod-reader

rules:

- apiGroups: [""] # "" indicates the core API group

resources: ["pods"]

verbs: ["get", "watch", "list"]

master1 $ k get pods -n test --show-labels

NAME READY STATUS RESTARTS AGE LABELS

test-pod 1/1 Running 0 34s role=test,run=test-pod

testing 1/1 Running 0 17d run=testing

$ vim netpol.yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: deny-network

namespace: test

spec:

podSelector: {}

policyTypes:

- Ingress

- Egress

master1 $ k apply -f netpol.yaml

Explanationcontrolplane $ k get pods -n test --show-labels

NAME READY STATUS RESTARTS AGE LABELS

test-pod 1/1 Running 0 34s role=test,run=test-pod

testing 1/1 Running 0 17d run=testing

master1 $ vim netpol1.yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: deny-network

namespace: test

spec:

podSelector: {}

policyTypes:

- Ingress

- Egress

master1 $ k apply -f netpol1.yaml

1) Connect to correct host

ssh cks000033

sudo -i

export KUBECONFIG=/etc/kubernetes/admin.conf

2) Patch the ServiceAccount to disable automounting

Task: turn off automounting of API credentials for stats-monitor-sa in monitoring.

kubectl -n monitoring patch sa stats-monitor-sa -p '{"automountServiceAccountToken": false}'

Verify:

kubectl -n monitoring get sa stats-monitor-sa -o yaml | grep -i automount

3) Edit the Deployment manifest file

Task says to modify the manifest at:

/home/candidate/stats-monitor/deployment.yaml

vi /home/candidate/stats-monitor/deployment.yaml

4) In the Deployment, ensure it uses the ServiceAccount AND inject token via Projected Volume

4.1 Make sure Deployment uses the SA

Under:

spec: -> template: -> spec:

ensure:

serviceAccountName: stats-monitor-sa

(If it already exists, leave it; don’t add extra changes beyond requirements.)

4.2 Add a projected volume named token

Under:

spec: -> template: -> spec: -> volumes:

add (or modify existing volume if present) so it is exactly:

- name: token

projected:

sources:

- serviceAccountToken:

path: token

This creates the file token inside the mounted directory, so the final path becomes:

/var/run/secrets/kubernetes.io/serviceaccount/token

4.3 Mount the projected volume read-only at the required location

Under the target container:

spec: -> template: -> spec: -> containers: -> (your container) -> volumeMounts:

Add:

- name: token

mountPath: /var/run/secrets/kubernetes.io/serviceaccount

readOnly: true

✅ This satisfies:

Projected volume name: token

Mount path: /var/run/secrets/kubernetes.io/serviceaccount/token (file inside mount)

Mounted read-only

4.4 Important: Don’t break default token mount behavior

Because you disabled SA automounting at the ServiceAccount level, you must explicitly mount the projected token (done above). That’s the whole point of this task.

Save and exit:

wq

5) Apply the updated Deployment

kubectl -n monitoring apply -f /home/candidate/stats-monitor/deployment.yaml

Wait rollout:

kubectl -n monitoring rollout status deployment/stats-monitor

6) Verify the token file exists in the running Pod

Get a pod name:

POD=$(kubectl -n monitoring get pods -l app=stats-monitor -o jsonpath='{.items[0].metadata.name}')

echo $POD

Check the token file path exists:

kubectl -n monitoring exec -it $POD -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/token

Optional: confirm it’s mounted read-only (usually shown by mount options):

kubectl -n monitoring exec -it $POD -- mount | grep /var/run/secrets/kubernetes.io/serviceaccount

✅ What the examiner checks

SA stats-monitor-sa has:

automountServiceAccountToken: false

Deployment stats-monitor mounts a projected volume named token

Token file is at:

/var/run/secrets/kubernetes.io/serviceaccount/token

Mount is readOnly: true

If label selector doesn’t match (-l app=stats-monitor)

Use:

kubectl -n monitoring get pods

Then set:

POD=

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

}

[desk@cli] $ k create sa backend-qa -n qa

sa/backend-qa created

[desk@cli] $ k get role,rolebinding -n qa

No resources found in qa namespace.

[desk@cli] $ k create role backend -n qa --resource pods,namespaces,configmaps --verb list

# No access to secret

[desk@cli] $ k create rolebinding backend -n qa --role backend --serviceaccount qa:backend-qa

[desk@cli] $ vim /home/cert_masters/frontend-pod.yaml

apiVersion: v1

kind: Pod

metadata:

 name: frontend

spec:

 serviceAccountName: backend-qa # Add this

  image: nginx

  name: frontend

[desk@cli] $ k apply -f /home/cert_masters/frontend-pod.yaml

pod created

[desk@cli] $ k create sa backend-qa -n qa

serviceaccount/backend-qa created

[desk@cli] $ k get role,rolebinding -n qa

No resources found in qa namespace.

[desk@cli] $ k create role backend -n qa --resource pods,namespaces,configmaps --verb list

role.rbac.authorization.k8s.io/backend created

[desk@cli] $ k create rolebinding backend -n qa --role backend --serviceaccount qa:backend-qa

rolebinding.rbac.authorization.k8s.io/backend created

[desk@cli] $ vim /home/cert_masters/frontend-pod.yaml

apiVersion: v1

kind: Pod

metadata:

 name: frontend

spec:

 serviceAccountName: backend-qa # Add this

  image: nginx

  name: frontend

[desk@cli] $ k apply -f /home/cert_masters/frontend-pod.yaml

pod/frontend created

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: network-policy

spec:

podSelector: {} #selects all the pods in the namespace deployed

policyTypes:

- Ingress

ingress:

- ports: #in input traffic allowed only through 80 port only

- protocol: TCP

port: 80

1) Connect to the correct host

ssh cks000037

sudo -i

2) Remove user developer from the docker group ONLY

2.1 Verify current groups (optional but fast)

id developer

2.2 Remove ONLY from docker group

gpasswd -d developer docker

2.3 Verify removal

id developer

✅ docker should not appear; other groups must remain.

3) Reconfigure Docker to secure the socket and disable TCP

Docker config file:

vi /etc/docker/daemon.json

3.1 Set socket group to root and disable TCP listeners

Ensure the file contains exactly these relevant settings (merge with existing JSON if present):

{

"group": "root",

"hosts": ["unix:///var/run/docker.sock"]

}

Important:

"group": "root" → docker.sock owned by group root

"hosts" includes ONLY the unix socket (no tcp://)

If the file already exists with other keys, add/adjust only these keys and keep valid JSON (commas!).

Save and exit:

wq

4) Restart Docker daemon

systemctl daemon-reload

systemctl restart docker

systemctl status docker --no-pager

5) Verify Docker socket ownership and permissions

ls -l /var/run/docker.sock

Expected:

srw-rw---- 1 root root ...

✅ Owner: root

✅ Group: root

6) Verify Docker is NOT listening on TCP

ss -lntp | grep docker

Expected:

No output (or nothing bound to TCP by dockerd)

Optional double-check:

ps aux | grep dockerd | grep -v grep

Ensure no -H tcp://... flags.

7) Ensure Kubernetes cluster is healthy

7.1 Check node and pods

export KUBECONFIG=/etc/kubernetes/admin.conf

kubectl get nodes

kubectl get pods -A

All nodes should be Ready, core pods Running.