Kubernetes has truly become the go-to choice for running containerized workloads. The level of automation, flexibility, and its declarative configuration model simplifies/lessens/removes a huge operational overhead when managing, computing, storage, and networking.
It is also true that because of the fast pace of Kubernetes adoption, the level of flexibility of configurations it allows, the number of tooling options available, and the complexity behind microservices architectures, a new set of security problems and cognitive demand have been created for teams trying to keep up, making containers and Kubernetes an ideal target for attackers.
There are many vulnerabilities which can be intentionally exploited to gain unauthorized access, disrupt services, and/or cause data breaches. In the same way, there are a lot of misconfigurations that can cause problems, such as increased costs and inefficient use of resources.
Recent surveys have highlighted the prevalence of vulnerabilities in Kubernetes clusters:
- According to a survey conducted by RedHat in 2022, 93% of respondents reported experiencing “at least one security incident in their Kubernetes environments in the last 12 months” with 53% being attributed to misconfigurations and 38% being a result of vulnerabilities being exploited.
- A 2023 RedHat report also notes that 67% of respondents reported delayed or slowed deployment due to Kubernetes security concerns, 37% experienced revenue or customer loss due to a container/Kubernetes security incident, and 90% had had at least one security incident in the past 12 months.
To inform this conversation a little more, let’s cite some very common examples of vulnerabilities and misconfigurations found in Kubernetes clusters, which often go unnoticed due to lack of knowledge or lack of tools that can correctly identify them:
Pod Resource Requests and Limits
Kubernetes is designed to allocate resources based on user-defined requests and limits. If these definitions are incorrect, the allocation of resources needed to run containers efficiently will be severely compromised.
If the defined requests and limits are too high, Kubernetes can allocate more resources than necessary, leading to inefficient usage and increased costs. On the other hand, if they are too low, it can allocate insufficient resources, leading to performance issues, downtime, and even data loss.
Therefore, it is essential to define them correctly to ensure that containers have access to the necessary resources to function efficiently and avoid performance issues, downtime, and data loss.
Misconfigured security contexts
Escalation of privileges, unauthorized access, denial of service, data loss, and compliance violations are just a few of the possible consequences of misconfigured security contexts.
An overly permissive security context in a container can provide attackers with escalated privileges within the container or even on the host node, allowing them to gain unauthorized access to sensitive resources such as secrets or configuration data. This can also leave containers vulnerable to DoS attacks, where the attacker can exhaust the resources of the container or host node.
Compliance violations, such as those under HIPAA or GDPR, may also occur due to misconfigured security contexts, leading to legal and financial penalties.
To ensure the integrity, confidentiality, and availability of data and resources, it is crucial to properly configure security contexts for containers and pods in Kubernetes.
Untagged Docker Image
A Docker tag provides a unique identity for a Docker image. If you don't specify a tag (or a digest) for an image, Kubernetes will assume that you are referring to the tag :latest. This can cause confusion when trying to track which version of the image is running and for it to roll back properly.
To solve this problem, it’s necessary to associate the tag or the digest of all the images referenced in the resources.
Regularly checking all images can quickly identify and fix any untagged images, reducing the risk of vulnerabilities and ensuring the integrity and security of the infrastructure environment as a whole.
Definition of probes
Probes are used to check the health of a container. They allow Kubernetes to automatically detect and recover from failures.
Defining probes on a resource can help ensure that the cluster is running efficiently and effectively.
Without a liveness probe, in the case that the web server process inside the container crashes, it wouldn’t automatically be restarted. This can lead to increased downtime for service as the website becomes unavailable until someone manually intervenes.
Without a readiness probe, the container running the web server may still be included in the load balancer's pool of available instances. This can lead to requests being sent to the container, which might not be able to handle them properly, resulting in errors or timeouts. For example, the web server may need to connect to a database or some external service before it's able to respond to incoming requests.
Additionally, not having both probes defined can make it difficult to diagnose and troubleshoot issues with the service, as there would be no automatic mechanism for identifying when the container is not functioning properly. This can lead to a delay in identifying and fixing issues, causing further downtime and impacting availability of service.
Conclusion
The potential damage that these vulnerabilities and misconfigurations are able to cause can be significant.
To avoid this, it is important to check all Kubernetes clusters on a regular basis to identify potential risks and fix them as quickly as possible. It is also important to implement best practices for Kubernetes cluster security, such as restricting access to sensitive resources, using secure network policies, and updating the environment regularly.
Zora can help you perform these periodic checks easily and automatically. It allows periodic scanning of all your K8s clusters via connected plugins such as Popeye and Marvin, Undistro's official plugin that reports updated checks with the latest vulnerabilities disclosed by leading frameworks (Kubernetes POD Security Standards, Mitre Att&ck, NSA & CISA Kubernetes Hardening Guidance). Other plugins are coming soon ;))
Visit undistro.io to learn more.
In conclusion, Kubernetes is an essential tool for managing containerized workloads but it also represents a significant risk to infrastructure security. By identifying and remedying vulnerabilities, organizations can reduce the risk of security incidents and data breaches and protect their critical infrastructure and data.