Top 10 Kubernetes Security Risks Every DevSecOps Pro Should Know

Kubernetes is the de facto container management platform in the modern cloud-native world. It makes it possible to develop, deploy, and manage microservices flexibly and scalably. Kubernetes works with various cloud providers, container runtime interfaces, authentication providers, and extensible integration points.

However, Kubernetes still has one major drawback: security. The integrator approach of Kubernetes to run any containerized application on any infrastructure makes it challenging to create holistic security around Kubernetes and the application stack living on it.

According to Red Hat's 2022 "State of Kubernetes" security report, the majority of Kubernetes users had their delivery halted due to unaddressed security concerns. In addition, over the course of the previous 12 months, almost every Kubernetes user in the study experienced at least one security incident. Therefore, it is fair to say that Kubernetes environments are not secure by default and are open to risks.

This article discusses the top 10 security risks with real-life examples and tips on how to avoid them.

1. Kubernetes Secrets

Secrets are one of the core building blocks of Kubernetes for storing sensitive data like passwords, certificates, or tokens and using them inside containers. There are three critical issues related to Kubernetes secrets:

2. Container Images With Vulnerabilities

Kubernetes is a container orchestration platform that distributes and runs containers on the worker nodes. However, it does not check the contents of containers for whether they have security vulnerabilities or exposures.

Therefore, it is necessary to scan the images before deployment to ensure that only images from trusted registries with no critical vulnerabilities (like remote code execution) will run on the cluster. Container image scanning should also be integrated into CI/CD systems for automation and detecting flaws earlier.

3. Runtime Threats

Kubernetes workloads — namely, containers — run on the worker nodes, and the containers are controlled by the host operating system in the runtime. If there are permissive policies or container images with vulnerabilities, they can open backdoors into your whole cluster. Therefore, OS-level runtime protection is required to enforce security in runtime, and the most important protection against runtime threats and vulnerabilities is to implement the least-privileged principle throughout Kubernetes.

Open source and widely accepted tools like Seccomp, SELinux, and AppArmor in the Linux kernel level are available to implement policies and restrict access. These tools are not internal to Kubernetes and require external configuration and effort to enable protection against runtime threats. In order to secure Kubernetes in an automated fashion, try employing the Kubernetes Security Posture Management (KSPM) approach. KSPM leverages automation tools to detect, fix, and alert security, configuration, and compliance issues using a holistic approach.

4. Cluster Misconfiguration and Default Settings

The Kubernetes API and its components consist of a complex set of resource definitions and configuration options. Therefore, Kubernetes offers default values for most of its configuration parameters and tries to remove the burden of creating long YAML files.

However, you need to be careful about three critical issues related to cluster and resource configuration:

5. Kubernetes RBAC Policies

RBAC is the Kubernetes-native method of managing and controlling authorization to Kubernetes resources. Therefore, configuring and maintaining RBAC policies is essential to secure the clusters from unwanted access.

There are two critical points to consider while working with RBAC policies. First, some RBAC policies are too permissive, such as the cluster_admin role, which can do basically everything in the cluster. These roles are assigned to regular developers to make them more agile. However, in the event of a security breach, attackers quickly get high-level access to the clusters using cluster_admin. To avoid this, you should configure RBAC policies for specific resources and assign them to particular user groups.

Second, in general, various environments, like development, testing, staging, and production, exist in the software development life cycle. In addition, there are multiple teams with different focuses, such as developers, testers, operators, and cloud admins. RBAC policies should be assigned correctly for each group and each environment to limit exposure.

6. Network Access

In Kubernetes, a pod can connect to other pods and external addresses outside the cluster; others can connect to this pod from inside the cluster by default. Network policies are the Kubernetes-native resources to manage and restrict the network access between pods, namespaces, and IP blocks.

Network policies can also work with the labels on the pods, so inefficient use of labels could lead to unwanted access. In addition, when the clusters live in cloud providers, the cluster network should also be isolated from the rest of the virtual private cloud (VPC).

7. Holistic Monitoring and Audit Logging

When you deploy an application to a Kubernetes cluster, it's not sufficient to only monitor the application metrics. You must also watch the Kubernetes cluster's status, cloud infrastructure, and cloud controllers to have a holistic view of the complete stack. It is also important to watch for breaches and detect anomalies since intruders will be testing to access your clusters from every possible opening.

Kubernetes provides out-of-the-box audit logs for security-related incidents in the cluster. Still, you also need to collect the records from various applications and monitor their health in a central place.

8. Kubernetes API

Kubernetes API is the core of the entire system, where all internal and external clients connect and communicate with Kubernetes. If you deploy and manage Kubernetes components in-house, you need to be more careful because the Kubernetes API server and its components are open source tools with potential — and actual — vulnerabilities. Therefore, you should use the latest stable version of Kubernetes and patch live clusters as early as possible.

If you use cloud providers, the Kubernetes control plane is in control of the provider itself, so the cloud infrastructure updates and patches automatically. However, users are responsible for upgrading worker nodes in most cases. Therefore, you can use automation and resource provisioning tools to upgrade nodes easily or replace them with new ones.

9. Kubernetes Resource Requests and Limits

In addition to scheduling and running containers, Kubernetes can also limit the resource usage of containers in terms of CPU and memory. Although Kubernetes users mostly neglect them, resource requests and limits are critical for two reasons:

When the resource requests are calculated and assigned correctly, the whole cluster works efficiently in terms of CPU and memory. In addition, when resource limits are set, both faulty applications and intruders will be limited in terms of resource usage. For instance, if there are no resource limitations, a malicious container could consume nearly all of the resources in the node and make your application unusable.

10. Data and Storage

Although containers are designed to be ephemeral, Kubernetes makes it possible to run stateful containerized applications scalably and reliably. With the StatefulSet resource, you can deploy databases, data analytics tools, and machine-learning applications into Kubernetes quickly. The data will be accessible to the pods as volumes attached to the containers.

However, it is critical to limit access by policies and labels to avoid unwanted access by other pods in the cluster. In addition, storage in Kubernetes is provided by external systems, so you should consider using encryption for critical data in the cluster. If you manage your storage plugins, you should also check the security parameters to ensure that they are enabled.

Conclusion

Kubernetes is the indisputable container management platform for running microservice applications. However, holistic security is still one of its drawbacks, as it is not the core focus of the project. Therefore, you need to take extra steps to make your clusters and applications more secure.