CKS securityContext questions look scary until you realize they are mostly the same patterns repeated.
Here are the ones you should memorize to move fast during the CKS exam and CKS practice labs.
Pod vs container-level securityContext (quick rule)
- Pod-level securityContext = generic defaults for all containers
- Container-level securityContext = specific rules for one container
Exam trick:
If they say “Pod”, use Pod-level. If they say “container X”, use container-level. If unsure and lab checker is strict, apply runAs settings in both places.
1) runAsNonRoot + UID/GID
securityContext:
runAsNonRoot: true
runAsUser: 101
runAsGroup: 101
If strict checker, set both Pod-level and container-level:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 101
runAsGroup: 101
containers:
- name: app
securityContext:
runAsNonRoot: true
runAsUser: 101
runAsGroup: 101
2) allowPrivilegeEscalation false
securityContext:
allowPrivilegeEscalation: false
3) Drop ALL capabilities, add NET_BIND_SERVICE
securityContext:
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
4) readOnlyRootFilesystem true
securityContext:
readOnlyRootFilesystem: true
If app breaks, mount emptyDir for writable paths (often /tmp):
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
Fast verification (kubectl jsonpath)
kubectl -n security-context get pod secure-app -o jsonpath='{.spec.containers[0].securityContext.runAsNonRoot}{"\n"}'
kubectl -n security-context get pod secure-app -o jsonpath='{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}'
RBAC check:
kubectl auth can-i create rolebindings -n ci-cd --as=system:serviceaccount:ci-cd:ci-bot
Top comments (0)