Passing the CKS Exam
Since I’ve been working with Kubernetes since 2017 and have always been interested in information security, the Certified Kubernetes Security Specialist (CKS) looked like a great fit for me and my career going forward..
So, I recently set aside some time for self-study and scheduled my exam, which I passed, and I wanted to provide some advice and suggestions that I believe will help anyone trying to earn this certification prepare adequately and know what to anticipate on the exam.
Why get CNCF certified
As more organisations adopt Kubernetes and regard it as “highly essential” to cloud-native application strategy and report utilising Kubernetes particularly in production, they all agree that security of Kubernetes and containers is one of the most pressing concerns moving forwards.
This is highlighted by an increasing number of organisations reporting at least one security incident involving containers and/or Kubernetes, and that they are most concerned about unmet security and compliance needs when it comes to container strategy, as well as reporting having to delay application deployment due to container or Kubernetes security concerns.
Enter the Certified Kubernetes Security Specialist (CKS). Obtaining a CKS certifies a candidate’s ability to secure container-based applications and Kubernetes platforms during development, deployment, and runtime, and qualifies them to handle the responsibility of securing your Kubernetes deployment.
Exam Overview
This is a two-hour online, proctored, performance-based exam in which you must answer 15 questions from the command line that test the candidates abilities and knowledge to secure a Kubernetes Cluster and identify any threats and rectify them.
Before taking the CKS, candidates must have a current Certified Kubernetes Administrator (CKA) certification to demonstrate they have sufficient Kubernetes expertise. For the CKS Exam, a score of 67% or above must be earned to pass.
The certification exam assesses specific domains and competencies such as:
Cluster Setup
Cluster Hardening
System Hardening
Minimise Microservice Vulnerabilities
Supply Chain Security
Monitoring, Logging, and Runtime Security
How did I prepare? My Study Guide
The majority of my knowledge for this exam came from my daily work with Kubernetes over the last few years, particularly in regards to securing the environments I’ve been working with, however, to ensure I covered all of the topics for this exam in depth, I purchased Kim Wüstkamp’s Udemy course Kubernetes CKS 2022 Complete Course - Theory - Practice.
Along with this, I used the Killercoda Interactive Learning Interactive Scenarios, which are also brought to you by Killer.sh. You will find that these scenarios cover the necessary skills to a very high degree and will greatly assist you in preparing for the exam.
I also found and watched numerous online presentations centred on aspects of the exam that I felt I wanted to learn more about, such as Kubernetes Auditing, Containers and how they communicate with their hosts, and Kubernetes and Container Security. There are many excellent talks available, and I strongly advise you to use them to expand your knowledge.
I had previously chosen an excellent book by Packt Publishing Learn Kubernetes Security | Packt, which I had read but made sure to go over again the sections of the book that covered aspects of the exam.
Given my level of experience with Falco, I made sure to complete the Falco 101 course, which brought me up to speed and prepared me for this exam. I was also fortunate enough to have worked with Open Policy Agent, so I was able to use my knowledge and experiences to help me prepare for the exam.
In addition, I set up a learning environment using Minikube, and basically set myself the challenge of securing the cluster in every way possible based on what I learned about Kubernetes and Container Security, as well as replicating as many of the real-world scenarios and practise questions as possible. This method worked well in ensuring that I fully comprehended all of the topics.
Exam Overview
API Server
There are several different approaches to securing your cluster at the API Server level
Admission plugins
Make sure you understand Admission Controllers and their role in Kubernetes security, as well as their role in validating or rejecting API Server requests. You may be prompted to activate or disable admission controllers during the exam, so be aware of the —enable-admission-plugins and —disable-admission-plugins flags. Familiarise yourself with critical Admission plugins such as PodSecurityPolicy, NodeRestriction and ImagePolicyWebhook which you may be requested to enable.
Anonymous login
During the exam, you may be required to secure the API server against anonymous queries to the API server’s secure port, as well as know how to block requests with the username'system:anonymous and the group name system:unauthenticated Make sure you’re familiar with the ClusterRoleBindings for this user and group.
Auditing
The key to successful auditing is to keep in mind that it is a two-step procedure.
Part 1: Configure your Auditing Policy Make sure you understand what an audit policy is and how to create and change one, you may be asked to amend an existing policy to add more audits specific to certain resources at various levels during the exam. For additional information, see Auditing | Kubernetes.
Part 2: Enable API server-level auditing You must enable the required Auditing flags to verify that auditing is in place, the two flags that must be present are
--audit-policy-file : specifies the path to the Audit Policy, if the flag is omitted, no events are logged
--audit-log-path : specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend. - means standard outAdditionally the following flags can be included to help define other key Auditing parameters.
--audit-log-maxage defined the maximum number of days to retain old audit log files
--audit-log-maxbackup defines the maximum number of audit log files to retain
--audit-log-maxsize defines the maximum size in megabytes of the audit log file before it gets rotatedAuthorization Modes
The Kubernetes API server can authorise a request in one of several ways, learn what they are, how they function, and, most crucially, how to enable them if you are requested to do so in the exam. Remember that this is an ordered list, therefore the order is important.
Encrypting Data at Rest
Make sure you understand the ‘-encryption-provider-config’ setting and how to use and setup an encryption config file before using the API servers to manage how API data is encrypted in ‘etcd’.
ImagePolicyWebhook
Learn how to use the ‘imagePolicy’ file, which is used by the ‘ImagePolicyWebhook’ admission controller, and what each field in the Policy controls and how to change it. It’s also critical that you understand the significance and structure of the ‘kubeconfig’ file, which sets the backend connection and ensures that it points to the correct remote server.
Tip: If you use an API flag to point to a file, make sure you’ve made it available via a Volume and VolumeMount.
Container & Pod Security
Apparmor
When working with Apparmor in the exam, it is critical to identify the correct name of your Apparmor rule (do not assume the file name is the rule name) as well as the name of the container the rule will manage. Each container has its own AppArmor profile, to specify the AppArmor profile with which to run a Pod container, add the following annotation to the Pod’s metadata :
container.apparmor.security.beta.kubernetes.io/<container_name>**: <profile_ref>Tip: Know how to edit and load Apparmor rules and when applying a rule ensure you apply it to all nodes and validate it loaded with the aa-status command.
Manual Scanning
You might have to manually scan manifests or existing pods from time to time to confirm their integrity and that they are not presenting a security concern.
The most important things to look for if you’re asked to manually inspect a Dockerfile, Manifest, or running container are:
Use a specified Image Version in Container Config instead of the latest tag.
Make sure Container Config isn’t running as the “default” user, which is root If at all possible, use a different user.
Remove the ability for users to login to the container through a shell from the Container Config and Images.
When possible, use multi-stage builds.
Disable allowPrivilegeEscalation: false to prevent your Pod from increasing its privileges. This will prevent malicious binaries from being launched.
Protect your hosts by using readOnlyRootFilesystem: true to prevent Pods from writing to them. This will ensure that no harmful code is added to your hosts.
If possible, look for containers with privileged: true as a high security risk and modify it to false.
Runtime
As Kubernetes adopts ‘containerd’ as its default Container Runtime Interface (CRI), understanding Runtime Classes, how to implement them in Pods, and the CRI mode becomes increasingly important.
RuntimeClass resources are made up of two major fields: name(metadata.name) and handler (handler), and can be modified at the spec level within a pod.
spec: runtimeClassName: prodclassTip: When setting up a Runtime Class identify the associated handler name, which identifies the configuration, any exam questions you get on Runtime will provide this information.
Seccomp
Know that Seccomp’s role is to restrict the calls a process is able to make from the userspace into the kernel of which in Kubernetes is managed using seccomp profiles loaded onto a node, pod or container. Take the time to learn how to load seccomp profiles on a node and container, as well as how to apply a container runtime default seccomp profile, in preparation for the exam. Familiarize yourself with the ability to recognise and comprehend a breach of a seccomp profile.
Tip: A seccomp profile cannot be applied to a container that has privileged: true set in the container’s securityContext.
Trivy & Image scanning
During the exam you may be asked to review the images used by pods within a certain namespace and using Trivy to scan the images for certain vulnerabilities. Ensure you know how to utilise Trivy to scan images and filter the output, the exam permits you to access the Trivy documentation available at GitHub - aquasecurity/trivy
Tip: The kubectll cheat sheet offers a useful command for generating a list of both the pod name and image name using this command, amend the namespace accordingly. : kubectl get pods -A --output=custom-columns=“NAME:.metadata.name,IMAGE:.spec.containers[*].image” The output of this command will assist you to know which images you need to scan and what pods you may be asked to edit based on the results.
Network Security
Ingress
Prepare yourself by familiarising yourself with the concept of Ingress Controllers and, more importantly, the fundamental outline of an Ingress resource, as seen here: Ingress - Temple | Kubernetes Build the knowledge necessary to associate Hostnames with Ingress resources, as described here: Ingress - Hostnames | Kubernetes
Take the time to learn how to secure an Ingress using TLS, starting with the ability to set up the tls secret using a declarative way to save time, such as eg.
kubectl create secret tls space-tls-secret -n <namespace> \
--cert=path/to/cert/file \
--key=path/to/key/file
Ensure you reference the secret correctly as such
spec:
runtimeClassName: prodclassTip: Ensure you understand how to associate an Ingress resource with multiple services that each utilise their own path
Network Policies
Learning network policies and how they work is an important element of protecting any Kubernetes cluster; make sure to study them thoroughly and perform as many scenarios as possible to become as familiar with them as possible.
Knowing and understanding the three different methods for allowing traffic to or from the namespace where the network policy is functioning in either direction (ingress or egress).
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: space
- podSelector:
matchLabels:
app: frontend
It's also crucial that you understand how to enable traffic but restrict a specific IP address.
ingress:
- from:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 172.17.1.0/24If requested, block both 'tcp' and 'udp' port access as follows:
ports:
- protocol: TCP
port: 32000
- protocol UDP
port: 3200Tip: Take advantage of the Kubernetes documentation’s numerous pre-defined network policy examples. Network Policies | Kubernetes
Pod Security Policies
Despite the fact that Pod Security Policies are being phased out, the exam is based on the most recent version of Kubernetes, v1.23.x, which still employs them, so make sure you know how to use them.
If you are asked to generate a PodSecurityPolicy, it is strongly advised that you use the example pod security policy offered in the Kubernetes documentation as a template: Kubernetes Pod Security Policies
Tip: Don’t forget to assign a role to the PodSecurtyPolicy according on its resource-name.
RBAC
The RBAC API declares four types of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. Make sure you know how to create any of these resources on the fly and how to alter existing resources to change the resource they’re connected with or the permissions.
Tip: If you have the time, use the auth can-i command to verify that your RBAC permissions are configured appropriately, and that you can create RBAC polices using a declarative approach this will save you a considerable amount of time.
Secrets
Secrets Encoding
Concentrate on learning how to use secrets as an environment variable or a file on a volume in a pod. When generating a secret, make sure to use the appropriate type for the sort of secret you’re creating, such as generic for data and tls for tls secrets.
Tip: To save time in the exam, learn how to encode text to base64 in the command line and construct secrets using a declarative method.
Secrets Decoding
During the exam you may be asked to decode Kubernetes secrets and output them to a file, make sure you are understand how to locate secret data and how to decode it using the echo -n <secret-data> | base64 -d command
Tip: The kubectl cheatsheet offers a useful command you can leverage to automate this process, all you need to do is amend the secret name and namespace. Simply pipe the output to file, remembering to amend the file to match the requirements of the question.
kubectl get secret my-secret -o go-template=‘{{range $k,$v := .data}}{{“### “}}{{$k}}{{“\n”}}{{$v|base64decode}}{{“\n\n”}}{{end}}’Security Best Practices
Kubebench
Unlike in the real world, where Kubebench instructs you on how to follow security best practises, the exam will assess your ability to solve this problem using your Kubernetes skills rather than providing this critical information.
Tip: Make sure you know where essential files related to Kubernetes setup, such as the api-server, kube-controller, kube-scheduler, etcd, and kubelet, are located, as well as how to update and apply changes.
Third Party Tools
Falco
Falco is a popular and powerful tool for Runtime security, and if you’re new to Falco, we recommend taking the Falco 101 course, which will give you an overview of Falco, rules syntax, alerting, setup, and more. This course will give you a solid basis on which to answer and address any Falco-related questions that may appear on the exam.
Tip: Become familiar with the key files that Falco uses for its rules and monitoring, as well as how to alter or create rules and apply them. Don’t forget to consult the official and exam-approved Falco manual for help.
Open Policy Agent
Despite the fact that the exam is tool agnostic and that many other CNCF tools that are similar to Open Policy Agent are available, there is no purpose in losing valuable exam marks by failing to understand this tool. It is strongly advised that you instal OPA on your learning environment and familiarise yourself with Contraits, ConstraintTemplates and how OPA uses Configmaps to handle the rules that govern your environment. This will ensure that you are able to troubleshoot any difficulties that arise during the exam.
Final Thoughts
If you’ve prepared well, you should have no trouble passing this exam. Remember to get the quick and easy questions out of the way first, and don’t be afraid to flag and return to questions that you think will take up too much of your time. Remember to use the hints and predefined commands that are provided to you to make this exam easier to take and to give you more time to go over your answers.
Make sure the API server comes back up after you make changes, this is an easy way to lose marks due to a typo or formatting.
Given that the majority of current Kubernetes clusters are not self-managed, few users will have worked with the backend of Clusters, thus be sure to build up your own learning environment to assist you in becoming familiar with it.
Remember to practise, practise, practise the more you push yourself to learn the content included in this exam, the better you’ll be prepared to walk into the exam and secure your real-world cluster.
Good Luck or should I say R29vZCBMdWNr