CKS Certification Study Guide: Minimize Microservice Vulnerabilities

Previous Sections

As we continue the study guide for the Certified Kubernetes Security Specialist (CKS) program, be sure to check out the information and content breakdown from our previous CKS posts:

• CKS CNCF Announcement and Exam Study
• CKS Certification Study Guide: Cluster Setup in Kubernetes
• CKS Certification Study Guide: Cluster Hardening
• CKS Certification Study Guide: System Hardening

This blog references tools to set up a Kubernetes version 1.19 cluster and review the CKS – Cluster Setup section. There is the ability to create a Kubernetes cluster from our GitHub repository using Terraform and Rancher Kubernetes Engine (RKE) in Google Cloud Platform (GCP) or Amazon Web Services (AWS). This cluster environment will help to simulate a real Kubernetes environment instead of a local cluster. To get the cluster up and running, follow the readme.md that outlines what applications you will need and the repository’s general structure.

Section 4: Minimize Microservice Vulnerabilities

The fourth section of our study guide focuses on minimizing microservice vulnerabilities and securing pods at runtime. The Linux Foundation course outline highlights the following core concepts in their course outline.

1. Setup appropriate OS-level security domains using options such as Pod Security Policies (PSP), Open Policy Agent (OPA), and security contexts
2. Manage Kubernetes secrets
3. Use container runtime sandboxes in multi-tenant environments (e.g. gvisor, kata containers)
4. Implement pod-to-pod encryption using mTLS

This section takes up 20% of the total point total, and it is reasonable to assume 3-5 questions revolving around minimizing microservice vulnerabilities. Each question will also need to be completed in about 5-6 minutes on average during the exam. Below is an overview of the various concepts that the CKS will highlight in the minimizing microservice vulnerabilities section.

Core Concepts and Topics

Setup appropriate OS-level security domains using options such as Pod Security Policies (PSP), Open Policy Agent (OPA), and security contexts

Overall this section is the most vague regarding its concepts and what will be asked during the exam. As I mentioned in the previous blog, Pod Security Policies will be deprecated in Kubernetes version 1.21, and Open Policy Agent documentation is not listed as a resource used during the exam. Security contexts are here to stay, and test-takers should be well-versed in their implementation. While PSPs and OPA are useful to know about, I am unaware of how they will be incorporated into the exam.

Pod Security Policies

Even though PSPs will be deprecated, their functionality within Kubernetes clusters should be known. PSPs are a cluster-level resource that controls a wide variety of aspects from Linux capabilities to UIDs. Unfortunately, one criticism is their confusing application through role-based access control (RBAC) and subtle loopholes that can be exploited. PSPs are applied to the user and any pods they create, which means you need to be familiar with cluster-level roles to users, groups, and service accounts. Students must also be aware of the various controls under the PSP and utilize the `auth can-i` functionality to help debug any authorization issues.

Open Policy Agent

OPA has been integrated into the Kubernetes admission controller framework since version 3.0. The documentation is scant, so assume that if there is a question about it, it will be pulled directly from the blogs on kubernetes.io.

Security Context

Security context refers to the pod.spec and the permissions associated with each pod. Contexts can be set at the pod and container level, and a question focused on debugging and identifying escalating privileges is a simple example that may be used. Overall, any questions around security contexts are going to tie into topics such as seccomp and App Armor from the previous section and other privilege and access control settings.

Manage Kubernetes secrets

If you are taking the CKS, it means you have passed the CKA. You have already had to deal with secrets management from the first exam, so look for expanding that core concept here. Examples that focus on service account tokens or bootstrap token secrets seem like the next steps. As mentioned in this section, you can also guarantee that TLS secrets overlap with other core security concepts. Overall, focus on knowing how to implement secrets securely and ensure that other containers cannot access the secrets.

Use container runtime sandboxes in multi-tenant environments (e.g. gvisor, kata containers)

This is another interesting subtopic whose relevance to the exam is unclear. It is essential to understand container runtime sandboxes and their use cases. There may be a question in the exam asking you to implement a sandbox using the `runtimeClassName:` spec. The exam would have to provide you with gvisor or kata containers enabled in the cluster. The main issue is the lack of documentation from the list of sources you can reference during the exam.

Implement pod-to-pod encryption using mTLS

mTLS is a core concept to securing pod-to-pod communications. Although there may be an example that combines secrets, ingress, and mTLS into a single large question. I doubt that the exam will ask you to create the certificates. However, it is worth bookmarking certificate signing requests and understanding how to implement kubeconfig access and mTLS authentication credentials.

Learn More

The StackRox CKS study guide contains a list of more resources and the ability to create a Kubernetes 1.19 cluster. In the GitHub repository, six folders contain mock exam questions and answers. Make sure to star and watch the repository for new updates as you begin your quest to becoming a Certified Kubernetes Security Specialist.

---