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

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

AppArmor restricts container’s access to resources, is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide a greater in-depth defense. AppArmor can help to run a more secure deployment by restricting what containers are allowed to do, and/or provide auditing through system logs.

AppArmor It is configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc.

example of profile file named apparmor-example which denies all file writes

#include <tunables/global>

profile apparmor-example flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}

we need to copy and install AppArmor profile file on one worker node node-worker-1:

scp profile node-worker-1:/tmp
ssh node-worker-1
apparmor_parser /tmp/profile

we can validate installation via:

aa-status | grep apparmor-example
  apparmor-example

let’s make a label on the node on which we have installed AppArmor profile

k label node node-worker-1 apparmor=example

and create Deployment which uses AppArmor profile and is scheduled on apparmor=example node

k create deploy apparmor --image=nginx --dry-run=client -oyaml > deployment_apparmor.yaml

modify Deployment manifest

apiVersion: apps/v1
kind: Deployment
metadata:
   creationTimestamp: null
   labels:
      app: apparmor
   name: apparmor
spec:
   replicas: 1
   selector:
      matchLabels:
         app: apparmor
   strategy: {}
   template:
      metadata:
         creationTimestamp: null
         labels:
            app: apparmor
         annotations:             # ADD THIS
            container.apparmor.security.beta.kubernetes.io/nginx: \ localhost/apparmor-example        # ADD THIS
      spec:   
        containers:
         - image: nginx
         name: nginx
         nodeSelector:            # ADD THIS
            apparmor: example.    # ADD THIS
status: {}

and create Deployment

kubectl create -f ./deployment_apparmor.yaml

we can look at the events, we can see that the Pod container was created with the AppArmor profile apparmor-example:

kubectl get events | grep apparmor

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