GRC Viewpoint

What We Learned From Scanning 10K Kubernetes Clusters

Kubernetes has become a pervasive technology that provides users with the benefits like elasticity, scalability, automation and high availability. The ever-growing use of Kubernetes makes it an attractive attack surface.

Studies show that misconfigurations makeup 59% of all Kubernetes security incidents. This is very concerning, since 100% of scanned clusters have at least one misconfiguration and 38% have 14 misconfigurations.  In this article, we will explore the top 10 Kubernetes misconfigurations we found.

1. Beware of default settings

Clusters are often created with defaults settings. Regardless of whether you use self-hosted or managed, Kubernetes does not come secure by default.
Users must be intentional about securing their clusters.

2. Minimize the use of the cluster-admin role

The cluster-admin role in Kubernetes grants a user full access to all resources in the Kubernetes cluster.  By default, it is only assigned to the Kubernetes system user named “kube-admin”. However, additional users can be granted the cluster-admin role.

To limit the risk of misuse or accidental actions by cluster-admin users, it is recommended to follow the principle of least privilege and grant users only the permissions necessary to perform their tasks.

3. Do not run privileged containers

A privileged container has unrestricted access to the host system and can perform any action that a root user can perform. This can include accessing sensitive system files, modifying system settings, or even installing malware.

To mitigate the risk of privileged containers in Kubernetes, it is recommended to avoid using them whenever possible and to follow the principle of least privilege. This means running containers with the minimum necessary permissions and resources required to perform their tasks.

4. Block unnecessary network traffic

63% of clusters have workloads outside the cluster with no network policies. Without network policies, Kubernetes resources can communicate with each other freely and without restriction, which can leave the cluster vulnerable to attacks.

Using ingress and egress filtering in network policies is critical to protect network access points in a Kubernetes cluster.

5. Encrypt your Secrets

Secrets store sensitive data as base-64 encoded strings, but they are not encrypted by default. Anyone with API access can retrieve or modify a Secret, and so can anyone with access to the underlying data store (etc).

To mitigate this risk, secrets should be stored in a secrets object. In addition, encryption tools must be used in order to give them another layer of protection.

6. Do not store app credentials in configuration files

In Kubernetes, configuration files are typically stored in version control systems, such as Git. This makes it easy for anyone with access to the files to view and potentially misuse the credentials. Additionally, Kubernetes configuration files are often exposed to the cluster nodes, making them potentially vulnerable to attacks if the credentials are stored in plain text.

The recommendation is to treat app credentials as secrets and apply the same guidelines to them.

7. Harden your Linux environment

Hardening a Linux environment and securing a Kubernetes cluster are interrelated as Kubernetes runs on top of Linux and inherits many of its security settings and policies. Hardening the underlying Linux environment can help to secure the Kubernetes cluster by implementing security measures that limit the attack surface, reduce vulnerabilities, and enforce access controls.

We recommend using SELinux (Security-Enhanced Linux), which native to Kubernetes. It is a Linux kernel security module that provides an additional layer of access control beyond the traditional Linux file permissions.

8. Shield the control plane from untrusted networks

The control plane is the core of Kubernetes and gives users the ability to view containers, schedule new Pods, read Secrets, and execute commands in the cluster. Therefore, it should be protected.

It is recommended to avoid control plane exposure to the Internet or to an untrusted network. The API server runs on ports 6443 and 8080. The security recommendation is to block these ports with a firewall.

9. Add limits to resource policies

Limiting resource policies in Kubernetes involves setting limits on the amount of CPU and memory resources that can be used by pods in a cluster. This can be effective for preventing resource monopolization and denial-of-service (DoS) attacks.

However, from an operational perspective, setting policies that are too restrictive can cause inefficiencies or even application failures. Therefore, it is important to strike a balance between security and efficiency when setting resource policies in Kubernetes.

10. Protect your container file system

Unauthorized access to the container file system can be the source of significant security breaches. A compromised file system can lead to attackers gaining access to the host system or other containers too. Protecting the file system also helps to ensure the integrity of container images.

The recommendation is to use read-only file systems, limit access to the file system, sign container images, and implement runtime security measures.

Conclusion

Kubernetes has become an attractive attack surface for hackers as its adoption continues to grow. Every cluster has at least one misconfiguration. This article explored the top 10 misconfigurations we found and provided recommendations on how to avoid them. Organizations must take proactive measures to secure their Kubernetes clusters and protect against cyber-attacks.

By Oshrat Nir, Head of Product Marketing at ARMO

Related Articles

Latest Articles