Top Ways to Secure Kubernetes Clusters: From the Cluster Setup Domain

In January 2022, it was reported that over 900,000 Kubernetes instances had been accidentally exposed to the internet. Often, these misconfigurations happen during cluster setup, which is probably why 10% of the Certified Kubernetes Security Specialist (CKS) exam is dedicated to this very concept. 

In this article, we will cover three areas you should master before taking the exam: using network policies, leveraging CIS Benchmarks, and securing the Kubernetes Dashboard. A quick note, it’s assumed you have a basic understanding of networking concepts, such as request headers, YAML, and IP addresses.

Need Kubernetes Training?

If you haven’t used Kubernetes before or are new to the platform, CBT Nuggets has got you covered. You’ll find a variety of Kubernetes training to help you get up to speed, whether you are an administrator or developer. Check out our Kubernetes training — and then sign up for a 7-day free trial to start learning how to leverage the power of Kubernetes!

Use Network Security Policies to Restrict Cluster-level Access

When dealing with Kubernetes pods, it is important to know that the pods are open internally upon initial creation. A container can easily access other workloads within the cluster. For example, a bad actor with access to the cluster could create a pod, connect it to a database workload and steal data. Not good. This is where network policies come into play.

A network policy restricts the ingress and egress of traffic using various means. You can block traffic via IP addresses, ports, and pod labels. Here is a quick example of what a network policy would actually look like:

apiVersion:networking.k8s.io/v1

kind:NetworkPolicy

metadata:

  name:cbt-network-policy

  namespace:default

spec:

  podSelector:

    matchLabels:

      role:webapp

  policyTypes:

    - Ingress

  ingress:

    - from:

        - podSelector:

            matchLabels:

              role:frontend

      ports:

        - protocol:TCP

          port:6379

This network policy only applies to Ingress. Ingress here means traffic going to the pod, as opposed to Egress, which is traffic leaving the pods. In this example, the network policy applies to all pods labeled webapp. Then, narrowing it down, the ingress rule applies only to the label frontend. Overall, this means that traffic coming to the pod with label webapp and frontend can only travel through port 6379 using TCP protocol. 

Use CIS Benchmarks to Review Security Configurations

The Center for Internet Security (CIS) is a nonprofit entity created to identify, develop, validate, and sustain best practice solutions for cyber defense. To pass the CKS, you must know how to compare CIS benchmarks to numerous Kubernetes configurations. Specifically, areas related to the etcd folder, the kubelet, kubedns, and kubapi. The CIS Benchmark PDF can be downloaded from the CIS website.

Let’s go over a quick example of how the benchmark can be used. Let’s say you have recently created an API server to be used on your Kubernetes cluster. Now that everything is functionally correct, you may want to check your configuration against the CIS standards.

The image above is a table of contents from the CIS Benchmarks, displaying the steps required to ensure your API server is properly secured. In order to have a valid API server, ensure all the steps are taken above, and your API server is still functioning correctly. It is imperative to be familiar with these benchmarks prior to taking the CKS.

Securing Kubernetes GUI

The last aspect of securing your cluster at setup is ensuring limited access to the Kubernetes GUI. The Kubernetes Dashboard is a useful tool for managing all of your Kubernetes resources. However, since it is such a handy tool, it is a common attack vector used to gain access to Kubernetes clusters.

Restricting the Kubernetes GUI can be accomplished through proper Role-Based Access Control (RBAC) configuration. In Kubernetes, RBAC is created via the RoleBinding resource. Always ensure people are given least-privilege access by default, then provide requests as the user needs them.

A second way to secure the GUI is via Token authentication. Token authentication is prioritized by the Kubernetes Dashboard. The token is in the format Authorization: Bearer <token> and it is located in the request header itself. Bearer Tokens are created through the use of Service Account Tokens. These are just a few of the K8s dashboard concepts that will wind up on the CKS. Make sure you have a thorough understanding of service accounts and how they relate to the Kubernetes Dashboard prior to taking the exam.

Final Thoughts

It’s fair to say we covered a lot of ground in this article. We discussed restricting access to pods using a network policy. After that, we went into detail about how to utilize the CIS Benchmark guide to ensure your cluster has been set up in a secure manner. Lastly, we discussed different ways to restrict the Kubernetes dashboard in production and non-production environments.

Earning the CKS is a long, difficult journey. However, by sticking to the subjects referred to in the CKS syllabus and practicing them every day, you should increase your odds of exam-day success.