How to Secure and Protect Your Kubernetes Cluster?

Originally published by ARMO here.

Written by Rotem Refael, Director of Engineering, ARMO.

Kubernetes is the de-facto container management platform of today and the future. It has increased the scalability and flexibility of applications and eliminated vendor lock-in. Kubernetes also brings a lot of security native features; however, with security, the devil is always in the details.

By default, the security of cloud services, applications, and infrastructure is not in the scope of Kubernetes. This does not mean that running Kubernetes is destructive and makes your applications vulnerable. There are well-known methods to run Kubernetes securely.

This blog post will discuss the Kubernetes attack surfaces and how to secure your cluster against attacks.

Kubernetes Architecture and Security Features

Kubernetes is a complex system composed of multiple layers and services, each of which reveals a hidden abstraction of Kubernetes resources and operational logic. Therefore, securing a Kubernetes cluster is not easy and requires in-depth understanding. Kubernetes offers essential security features out of the box, such as authentication and role-based access control (RBAC). Kubernetes administrators only need to configure the features wisely to secure their clusters. However, the security of nodes and containers does not fall within the scope of Kubernetes. Luckily, there are third-party tools to fill this gap.

Kubernetes Components and Potential Attack Surfaces

To protect your Kubernetes cluster, you have to understand the complete stack and potential vulnerabilities, namely the various Kubernetes attack surfaces. Kubernetes clusters consist of a control plane and multiple nodes, with the following services running in a distributed way:

Figure 1: Kubernetes components (Source: Kubernetes documentation)

The control plane is a critical part of a Kubernetes cluster, as it is the brain of a cluster. If hackers can reach the control plane, they can do everything—even delete the whole cluster. The nodes make up the second attack surface, where the actual applications are run. When an intruder gets into a node, they can deploy malicious applications and exploit the data of other applications running on the same node.

The third critical part of Kubernetes that can be vulnerable to attack is the cloud provider, where the Kubernetes clusters and nodes run as managed services that are reachable by external users.

The fourth and last attack surface is not shown in the diagram above; it is the actual applications running on the nodes. Applications run as containers with their dependencies, which means they are controlled by application developers. When a hacker exploits a vulnerability at this level, they can access sensitive data and change the application's behavior.

In the following sections, we’ll dive into the details of each attack surface and discuss preventive measures to secure your Kubernetes clusters.

Control Plane and Kubernetes API

The control plane is the collection of core services that make Kubernetes machinery work. These services make decisions about the running applications, distribute them over the nodes, and run the Kubernetes API.

The Kubernetes API has built-in security measures and only accepts authenticated and authorized requests. There are three ways you can ensure that your Kubernetes API and access to the control plane are secure.

RBAC (Role-Based-Access-Control) Policies

These manage authentication and authorization in the Kubernetes API, so it’s critical to have well-defined policies to protect Kubernetes clusters. However, RBAC policies can be complicated to manage when they are high in number. Kubescape from ARMO simplifies RBAC management by providing easy-to-understand graphs.

Figure 2: RBAC visualizer in Kubescape

Admission Controllers

These evaluate the requests after authentication and authorization. You can use them as a security measure to defend the Kubernetes API from unwanted changes. Admission controllers also enable administrators to create more fine-grained policies in the cluster than RBAC provides.

IP Range Limits

You can also secure the control plane components and the Kubernetes API at the network level by limiting the IP range of incoming requests; additionally, you should limit network access to control plane components using classic network segmentation (limiting IP access).

Nodes and Network

Kubernetes nodes run containerized applications and are usually container-optimized Linux VMs. It’s also possible to have bare metal nodes in on-premises data centers, but virtual machines are more scalable and flexible.

There are four essential ways to protect Kubernetes nodes:

• Remove extra applications, libraries, or operating system components and switch to a more minimalist operating system.
• Remove additional users from nodes.
• Ensure that no application in Kubernetes runs with root access.
• Use operating-system hardening tools like AppArmor or SELinux.

Nodes and the applications running on them are connected via cluster networking. Kubernetes creates unified networking between each pod in the cluster so that they can reach each other via their IPs or service names. It is a very niche feature when hundreds of nodes are running in the data center, but it is also highly open to security breaches.

There are three critical factors for ensuring the Kubernetes network is secure:

• Enforce network policies to isolate Kubernetes clusters from the external world as much as possible.
• Enforce network policies to isolate the network of pods that work with sensitive data.
• Monitor the network for potential breaches.

Application Layer and Containers

Kubernetes applications run as pods that consist of multiple containers. In each container, there are microservice applications packaged with their dependencies. In addition, the applications work with sensitive data that are stored in Kubernetes volumes. Therefore, it is critical to ensure that your pods, containers, and data storage are secure.

Security Contexts

Make sure to configure and use security contexts at the pod and container levels. Security contexts ensure that access control is limited, root access is managed, and system calls are controlled.

Container Images

Scan container images to make sure they are free of vulnerabilities. This is a critical step before deploying applications to the clusters since a container image with a vulnerability could run on the scale of hundreds and open hundreds of backdoors to attackers.

Using Kubescape from ARMO, you can scan the container images and see the details of any vulnerability as well as available patches:

Figure 3: Image scanning in Kubescape

Zero-Trust

Lastly, always implement a zero-trust policy for your applications running on Kubernetes. This means that every application must verify other applications before consuming services from them. Implementing zero-trust is difficult when applications are small and distributed.

Cloud Services

Cloud services are managed by the cloud providers that run your Kubernetes clusters. When attackers access cloud services, they can reach your Kubernetes clusters, databases, and stored data in the cloud. Therefore, it is essential to secure this primary gate endpoint via three primary actions:

• Define metadata for all the cloud resources and ensure said data is consistent between regions and services.
• Define user groups based on your teams and environments and limit access to the resources.
• Implement two-factor authentication for real users and additional security measures for technical users.