CKS Certified Kubernetes Security Specialist (CKS) Questions and Answers

se kubectl to create a CSR and approve it.

Get the list of CSRs:

kubectl get csr

Approve the CSR:

kubectl certificate approve myuser

Retrieve the certificate from the CSR:

kubectl get csr/myuser -o yaml

here are the role and role-binding to give john permission to create NEW_CRD resource:

kubectl apply -f roleBindingJohn.yaml --as=john

rolebinding.rbac.authorization.k8s.io/john_external-rosource-rb created

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

name: john_crd

namespace: development-john

subjects:

- kind: User

name: john

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: ClusterRole

name: crd-creation

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

name: crd-creation

rules:

- apiGroups: [ " kubernetes-client.io/v1 " ]

resources: [ " NEW_CRD " ]

verbs: [ " create, list, get " ]

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

To add a Kubernetes cluster to your project, group, or instance:

Navigate to your:

Project’s  Operations > Kubernetes  page, for a project-level cluster.

Group’s  Kubernetes  page, for a group-level cluster.

Admin Area >   Kubernetes  page, for an instance-level cluster.

Click  Add Kubernetes cluster .

Click the  Add existing cluster  tab and fill in the details:

Kubernetes cluster name  (required) - The name you wish to give the cluster.

Environment scope  (required) - The  associated environment  to this cluster.

API URL  (required) - It’s the URL that GitLab uses to access the Kubernetes API. Kubernetes exposes several APIs, we want the “base” URL that is common to all of them. For example,  https://kubernetes.example.com  rather than  https://kubernetes.example.com/api/v1 .

Get the API URL by running this command:

kubectl cluster-info | grep -E ' Kubernetes master|Kubernetes control plane ' | awk ' /http/ {print $NF} '

CA certificate  (required) - A valid Kubernetes certificate is needed to authenticate to the cluster. We use the certificate created by default.

List the secrets with  kubectl get secrets , and one should be named similar to  default-token-xxxxx . Copy that token name for use below.

Get the certificate by running this command:

kubectl get secret < secret name > -o jsonpath = " {[ ' data ' ][ ' ca \. crt ' ]} "

1) Connect to the correct host

ssh cks000032

sudo -i

2) Use admin kubeconfig

export KUBECONFIG=/etc/kubernetes/admin.conf

3) Verify prerequisites (quick check)

These should already exist per task.

kubectl -n prod get svc web

kubectl -n prod get secret web-cert

kubectl get pods -n ingress-nginx

(If the ingress controller pods exist, you’re good.)

4) Create the Ingress resource

Create Ingress named web in namespace prod with:

host: web.k8s.local

all paths → Service web

TLS using Secret web-cert

HTTP → HTTPS redirect (NGINX)

cat < < EOF | kubectl apply -f -

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web

namespace: prod

annotations:

nginx.ingress.kubernetes.io/ssl-redirect: " true "

nginx.ingress.kubernetes.io/force-ssl-redirect: " true "

spec:

ingressClassName: nginx

tls:

- hosts:

- web.k8s.local

secretName: web-cert

rules:

- host: web.k8s.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web

port:

number: 80

EOF

5) Verify Ingress creation

kubectl -n prod get ingress web

kubectl -n prod describe ingress web

Confirm:

Host = web.k8s.local

TLS Secret = web-cert

Backend Service = web

6) Test HTTP → HTTPS redirect

curl -L http://web.k8s.local

Expected:

Redirects to https://web.k8s.local

Returns application response over HTTPS

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/ < THE_FILE_YOU_FOUND > .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) SSH to the right node

ssh cks000002

sudo -i

2) Fix kubelet CIS findings

2.1 Edit kubelet config (MAIN place in kubeadm clusters)

vi /var/lib/kubelet/config.yaml

A) Set anonymous-auth to false

Find (or add) this block exactly :

authentication:

anonymous:

enabled: false

B) Use Webhook authentication (recommended by task)

Ensure this exists under authentication :

webhook:

enabled: true

C) Use Webhook authorization and NOT AlwaysAllow

Find (or add) this block exactly :

authorization:

mode: Webhook

When done, your file should contain something like this (exact structure to aim for):

authentication:

anonymous:

enabled: false

webhook:

enabled: true

x509:

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

authorization:

mode: Webhook

If x509: section isn’t there, it’s usually already present in kubeadm; don’t panic. Only the task-required parts are: anonymous false + webhook enabled + authorization mode Webhook.

2.2 Restart kubelet (required for config.yaml changes)

systemctl daemon-reload

systemctl restart kubelet

systemctl status kubelet --no-pager

Quick confirm (optional but fast):

grep -nE " anonymous|webhook|authorization|mode " /var/lib/kubelet/config.yaml

3) Fix etcd CIS finding: --client-cert-auth=true

3.1 Edit etcd static pod manifest (kubeadm path)

vi /etc/kubernetes/manifests/etcd.yaml

Find the container command: args that look like:

- command:

- etcd

- --something=...

Ensure this line exists exactly in the list:

- --client-cert-auth=true

Also ensure this is present (usually already is, but add if missing):

- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

Example snippet (what you want the args area to include):

- command:

- etcd

- --client-cert-auth=true

- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

3.2 Apply etcd change (auto-restart happens)

Just save the file . Kubelet will restart etcd automatically.

Watch it restart (pick one depending on runtime):

If Docker runtime (your task mentions Docker):

docker ps | grep etcd

If you don’t see it briefly, wait 2–5 seconds and rerun:

docker ps | grep etcd

(Alternative if available)

crictl ps | grep etcd

4) Final quick validation (fast exam check)

Kubelet config check

grep -n " enabled: false " -n /var/lib/kubelet/config.yaml | head

grep -n " webhook " /var/lib/kubelet/config.yaml

grep -n " authorization " /var/lib/kubelet/config.yaml

etcd arg check

grep -n " client-cert-auth " /etc/kubernetes/manifests/etcd.yaml

root# netstat -ltnup

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 1293/dropbox

tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 1293/dropbox

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd

tcp 0 0 127.0.0.1:9393 0.0.0.0:* LISTEN 900/perl

tcp 0 0 :::80 :::* LISTEN 9583/docker-proxy

tcp 0 0 :::443 :::* LISTEN 9571/docker-proxy

udp 0 0 0.0.0.0:68 0.0.0.0:* 8822/dhcpcd

root# netstat -ltnup | grep ' :22 '

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd

The  ss  command is the replacement of the  netstat  command.

Now let’s see how to use the  ss  command to see which process is listening on port 22:

root# ss -ltnup ' sport = :22 '

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port

tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:( " sshd " ,pid=575,fd=3))

$ kubectl get ing -n < namespace-of-ingress-resource >

NAME HOSTS ADDRESS PORTS AGE

cafe-ingress cafe.com 10.0.2.15 80 25s

$ kubectl describe ing < ingress-resource-name > -n < namespace-of-ingress-resource >

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 ( < none > )

/coffee coffee-svc:80 ( < none > )

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 < namespace-of-ingress-controller >

NAME READY STATUS RESTARTS AGE

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

$ kubectl logs -n < namespace > ingress-nginx-controller-67956bf89d-fv58j

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

NGINX Ingress controller

Release: 0.14.0

Build: git-734361d

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

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

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

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: < your-container-name >

image: < unchanged >

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.