Dec 10, 2020

CKS Certification Study Guide: Cluster Setup in Kubernetes

By: Michael Foster

This is the first installment in our six-part CKS Certification series. Don’t forget to check out all the posts in the series:

As we dive into studying for the Certified Kubernetes Security Specialist (CKS) program, make sure to understand the test and its structure. A full blog details the Cloud Native Computing Foundation’s (CNCF) announcement about the CKS and its exam structure.

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 will help to simulate a real Kubernetes environment instead of a local cluster. To get the cluster setup, follow the readme.md that outlines what applications you will need and the repository’s general structure.

Section 1: Cluster Setup

The first section focuses on controlling access to the Kubernetes cluster. The Linux Foundation course outline highlights the following core concepts.

  1. Use Network Policies to restrict cluster level access
  2. Use the CIS Kubernetes Benchmark to review the security configuration of Kubernetes components (etcd, kubelet, kube-dns, kube-api)
  3. Properly set up Ingress objects with security control
  4. Protect node metadata and endpoints
  5. Minimize use of, and access to, GUI elements
  6. Verify platform binaries before deploying

Knowing that this section takes up 10% of the point total, it is reasonable to assume 2 or 3 questions revolving around cluster setup. The questions will also need to be completed in about 5–6 minutes on average, so it is reasonable to assume that the questions will test your general knowledge without going into so many details that you are spending 10–15 mins per question.

With all of that out of the way, let’s walk through the core exam concepts and topics.

Core Concepts and Topics

1) Use Network Policies to restrict cluster level access

Network access between Kubernetes pods is open internally by default. A significant security risk associated with this setup is a container being able to access and connect to other workloads within the cluster network. Network Policies are the answer to this core vulnerability, which means Network Policies will, without a doubt, be in the exam.

Network Policies got an update in version 1.19, so it is worth reviewing the functionality and YAML structure changes. Also, make sure to bookmark these resources as they will come in handy for reference during the exam. If you’d like to learn more about Network Policies, Calico has some great demos, and our own Viswajith Venugopal has provided an extensive writeup of ingress and egress network policies. Lastly, our GitHub repo has multiple questions focused on default-deny policies and setting up ingress objects.

2) Use the CIS Kubernetes Benchmark to review the security configuration of Kubernetes components (etcd, kubelet, kube-dns, kube-api)

This topic is challenging to narrow down into specific questions. It requires knowledge of the CIS benchmarks that cover version 1.16 to 1.18. kube-bench is an open-source tool that runs validation of the Kubernetes components using the CIS benchmarks. It is worth knowing before the test; however, I would be surprised if it is a question since the webpage is not a listed resource that can be used during the test.

Knowing this, the focus shifts to verifying that the configuration files and binaries are secure on the host. Our GitHub questions contain simple checks on the host that make for easy exam questions.

3) Properly set up Ingress objects with security control

Kubernetes Ingress is another concept that will be in the test. Questions could include adding TLS to a previous ingress object or setting up an IngressClass. IngressClass was introduced in version 1.18 and helped to specify how different controllers should implement ingress objects. There are three types of Ingress controller setups to be aware of:

  • Cluster-wide Ingress Controller (default)
  • Single-namespace Ingress Controller
  • Ingress Controller for Specific Ingress Class

There are many different angles to ingress that may come up, so it is worth not narrowing it down in this blog. Over the course of this study guide, we will outline implementing TLS in Ingress objects and setting up Ingress objects and IngressClass objects.

4) Protect node metadata and endpoints

The topic says it all here. Protecting node metadata and endpoints is always a top concern. In previous Kubernetes versions, the kubelet had a read-only port, port 10255, that could be exploited to learn more about the pods running on the worker nodes. There could be a question where you have to reconfigure kubelet and disable the read-only port. However, the read-only capability has been deprecated, so it seems unlikely this would come up. It is worth knowing all of the endpoints that are required for the Kubernetes cluster to function.

Another use case might be a simple service check. There may be multiple services set up in the exam cluster, and then it is up to the student to weed out any unnecessary services and remove it. It will be worth brushing up on kubectl filtering capabilities and searching by spec.

5) Minimize use of, and access to, GUI elements

Similar to the previous concept, minimizing access to graphic user interface (GUI) elements is a significant security concern. This topic is fueled by previous security hacks that exposed the Kubernetes Dashboard to the public. To combat this issue, admins should set up internal-only facing dashboards with specific user access outlined in their configuration files.

There may be a question on the exam that requires changing NodePort services or proxying to a dashboard. Another option could be minimizing the permissions of a Dashboard within the cluster. Regardless, making sure that GUI elements are secure should always be a top priority during cluster setup.

6) Verify platform binaries before deploying

Kubernetes binaries can be verified by referencing their specific checksum in GitHub. Since exam takers will have access to the Kubernetes GitHub repository, it is worth bookmarking the release section and understanding how to verify binary SHA256 hashes.

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.