How to pass CKS — Kubernetes Security Specialist exam. Part 1

CKS certification is a performance-based, hands-on exam that tests knowledge of K8s security in a simulated, real-world environment. I had 15 different tasks and 120 min to complete them. 68 % required to pass.

CKS requires CKA (Certified Kubernetes Administrator) passed first. It is a mandatory pre-request. I shared my tips in a different post on how to pass CKA and CKAD. If you received CKA, know how to use kubectl and Kubernetes documentation in an efficient way, you can start study for CKS. CKS is harder than the other two K8s exams. Good preparation requires deep study of native and external Kubernetes security tools, best security practices, and also requires a good knowledge of Kubernetes architecture, especially about API server, etcd, and kubelet. The exam covers the following areas: gVisor, AppArmor, RBAC, Network Policies, Auditing, Falco,Trivy, Admission Controllers, CIS Benchmark, Pod Security Policies, writing secure Dockerfiles, Secrets, Privileged Pods.

In the next episodes, I will share my experience of how to solve the exam tasks. I keep tips in the GitHub repo

  1. Episode — Network Policies
  2. Episode — gVisor
  3. Episode — Trivy
  4. Episode — AppArmor
  5. Episode — PodSecurityPolicies
  6. Episode — RBAC
  7. Dockerfile & SecurityContext

Network Policies

Configure bash auto-completion on Linux before you start the exam:

Network Policies are an important topic on the exam. If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you should use K8s Network Policies. By default, all pods in a cluster can communicate with any other pod on the same cluster, including pods from different namespaces, and this includes the main kube-system namespace where the control plane is hosted. Unless changed, this is the network policy that is configured when you install Kubernetes and deploy your cluster. Network policies specify how groups of pods are allowed to communicate with each other and other network endpoints. You can think of them as the Kubernetes equivalent of a firewall.

“default-deny-all” network policy. It is a good practice to create default deny all Ingress traffic first and later Egress traffic in the namespace and just open necessary communication between pods or namespaces

(above) and (below) default deny

If we want to allow some traffic to or from Pods or namespaces, there are four kinds of selectors that can be specified in an section or section:

podSelector — selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations,

namespaceSelector -selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations,

namespaceSelector and podSelector - both selectors must match

namespaceSelector or podSelector - one selector in an array must match

problem 1 allow traffic to Pod with a label in namespace from pods in the namespace or from pods in the local Namespace with the label

solution — you need to explicitly set the label for namespace , the label is not added automatically during namespace creation

and apply the following YAML file (k apply -f file.yaml)

problem 2 — allow traffic from Pod with a label in namespace to pods in the namespace and with the label .

solution — let's create required label:

and apply the following YAML file (k apply -f file.yaml)

problem 3 allow traffic to all Pods in a namespace from pods in the namespace


and create the following network policy

if you need to display already existing labels

Examples from this post are available on GitHub. Thank you and see you soon in the next episode! The next post will be about gVisor.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store