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

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.

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

A PodSecurityPolicy is a cluster-level resource that controls security-sensitive aspects of the pod specification. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields.

Pod security policy control is implemented as an optional (but recommended) admission controller. Pod security policy can be enabled in API server configuration file.

API server config file kube-apiserver.yaml is located on the master node under /etc/kubernetes/manifest/, we need to add PodSecurityPolicy to API server flag--enable-admission-plugins

vim /etc/kubernetes/manifest/kube-apiserver.yaml

now, we can display now via kubectl get pspdefault pod security policy named default-allow-all

ok, let’s create our new PodSecurityPolicy , his policy prevents creation of privileged pods. The first step is to define policy in the YAML file

and via kubeclt create -f policy-file.yaml create it.

Our PSP has no effect because we also need to have yet a service account and RBAC permissions in place, Let’s also create them in namespace psp-test!

Role or ClusterRole needs to grant access to use the desired policies. Command can look like this (use help to generate correct syntax):

and build command

or it can be done via ready to use YAML

Then the (Cluster)Role is bound to the newly created service account via command (first help):

and build command

or it can be done via ready to use YAML

and via kubeclt create -f clusterrole.yaml and and via kubeclt create -f rolebinding.yaml create both of them!

Our new pspis visible via kubeclt get psp

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