OWASP Kubernetes Top 10 Overview

Kubernetes is pivotal to the cloud-native ecosystem. Yet, the platform is complex and prone to security misconfigurations. Insecure defaults, poor role-based access control (RBAC) or a lack of monitoring are just a few of the risks that plague Kubernetes in production.

These types of security risks not only leave Kubernetes vulnerable to attacks but delay the rollouts of new cloud-native applications. In fact, Red Hat’s 2023 State of Kubernetes Security Report found that 67% of respondents had to delay deployments due to security issues. Slightly more than one-third (37%) also experienced customer loss due to a container and Kubernetes security incident. Therefore, incentives exist within many areas of the organization to harden Kubernetes clusters.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

The OWASP Kubernetes Top 10, developed by Jimmy Mesta, co-founder and CTO at KSOC, accumulates some of the most pressing risks and vulnerabilities associated with developing on Kubernetes. They’re 10 cloud-native threats you’ll want to avoid. Below, I’ll briefly summarize each risk and highlight some security best practices to plug these gaps.

Overview of The OWASP Kubernetes Top Ten

K01: Insecure Workload Configurations

Kubernetes has a complex degree of workload configurations. But, insecure misconfigurations can quickly increase the attack surface area. For example, using root user all the time can expose many privileges if hacked. Other potential risks include needlessly providing write capabilities or setting containers to privileged.

K02: Supply Chain Vulnerabilities

Supply chain threats continue to be a potential risk for most software systems, and the Kubernetes build cycle and container runtime are no different. A Kubernetes deployment may comprise hundreds of containers, each relying on hundreds more dependencies. Open source projects may be susceptible to abuse and malicious code.

K03: Overly Permissive RBAC Configurations

In Kubernetes, RBAC determines users’ permissions to perform actions on resources. But, if RBAC isn’t configured correctly, it could open up Kubernetes to a significantly broader compromise. For example, if all users are granted cluster-admin superuser access, the deployment wouldn’t follow a least privilege model.

K04: Lack of Centralized Policy Enforcement

Modern cloud-native architecture is quite distributed and often runs across multiple clouds. But, a lack of centralized policy management can hinder governance and compliance around Kubernetes usage. For example, without a central policy in place against it, some areas of the system might allow images from untrusted registries.

K05: Inadequate Logging and Monitoring

Logging and monitoring are essential for diagnosing errors and spotting security incidents. But, if logging is disabled and administrators are not actively monitoring Kubernetes, attackers could go under the radar largely undetected. Thus, engineers should enable Kubernetes auditing and consider saving events and logs from other sources.

K06: Broken Authentication Mechanisms

Similar to authorization, authentication is also quite configurable and flexible in Kubernetes, providing different options for human operator and service authentication. If the authentication mechanism is broken or insecure, however, it could leave the cluster vulnerable to authentication by a third party.

K07: Missing Network Segmentation Controls

The state of network traffic is another area that may introduce security risks within Kubernetes. By default, components in Kubernetes can talk to one another. But without proper separation of workloads within a cluster, an attacker working within a compromised cluster could probe the network and perform lateral movement more easily.

K08: Secrets Management Failures

Sensitive data, like passwords or tokens, must be carefully stored. Otherwise, attackers could use these to log into administrative accounts. Specifically, Kubernetes secrets are standalone objects that hold, by default, unencrypted username and password pairs. These secrets should thus be encrypted at rest and carefully managed.

K09: Misconfigured Cluster Components

Each core component in a Kubernetes cluster is highly configurable, and insecure settings could cause security risks. For example, kubelet shouldn’t be configured to accept non-authenticated and non-authorized requests from other components. Attackers could leverage insecure configurations like this to escalate privileges and even enable a full account takeover.

K10: Outdated and Vulnerable Kubernetes Components

Vulnerabilities pop-up time and again within components that make up the Kubernetes ecosystem. For example, we’ve seen CVEs emerge around ArgoCD, ingress-nginx, and Istio service mesh. Since the software ecosystem around Kubernetes is so massive, avoiding vulnerable components is challenging. The best you can do is to continuously track and monitor for CVEs, and upgrade components when new patches are released.

Spotlight on KO2, Supply Chain Threats

The above checklist presents a comprehensive view of the risks associated with Kubernetes. And thankfully, infrastructure teams typically have a good handle on many of these risks above, according to Mehran Farimani, CEO of RapidFort. For example, they will usually have gatekeeper policies for K04 and K01 and utilize something like Istio for K07. However, what’s still a pressing concern, is K02: Supply Chain Vulnerabilities, said Farimani.

“K02 is a different beast! It could have any sort of vulnerability within third-party images, third-party packages within images and then the packages and libraries they use in turn,” Farimani said. “When working with one of the ‘big 4’ consultancy firms, they shared with us that ‘this is what dependency hell looks like!'”

Ironically, due to strict dependency checking and cross-dependencies, enterprises may be unable to upgrade dependencies even though fixes are available. Plus, not all scanners will provide deep visibility into the inner workings of clusters and their CVEs. Furthermore, Farimani found some of the OWASP advice around using distroless images to be impractical.

“Saying to go distroless or build from alpine/other, as suggested in K02, is much more impractical than it sounds,” Farimani added. “That’s a non-starter for many workloads and larger organizations. It’s asking them to replace vulnerability management with dependency management, requiring extensive engineering work.”

Ways to Defend Against These Risks

Although it may require a more nuanced approach to respond to Kubernetes-related supply chain threats, there are actionable steps for many of the other risks listed in the top ten. Here are some other methods to help ward off the above Kubernetes threats, as recommended by OWASP.

• When possible, avoid running applications within containers as root user or as privileged.
• Verify the provenance and integrity of dependencies and maintain a software bill of materials (SBOM).
• Perform usual bug fixes and security upgrades.
• Apply the principle of least privilege when assigning roles and permissions.
• Utilize built-in policy management features, or consider policy agents like Open Policy Agent (OPA) Gatekeeper, Kyverno and Kubewarden.
• Actively log and monitor Kubernetes events and store application, container and cloud provider logs.
• Minimize potential blast radius through network segmentation, either through multiple clusters or network policies.
• Carefully manage secrets and consider using an external secrets management tool for large networks.

In addition to the above tips, to avoid broken authentication issues, OWASP recommends not allowing certificate-based authentication or Service Account tokens from outside the cluster and encourages the use of multifactor authentication (MFA) and short-lived tokens.

Reducing Kubernetes Risk

Above, we’ve introduced tactics to avoid insecurities associated with Kubernetes adoption. These cloud-native security risks have been vetted by security researchers and stand as an essential checklist. If platform teams perform all these mitigations, risk should decrease substantially. Yet, this doesn’t negate the possibility for new vulnerabilities to emerge, such as defects within newly adopted security methods.

“The fact that many of these are well-known security areas and are straightforward to address means that organizations actually have many covered already,” said Farimani. “Still, the community may need help with a couple of items, and practitioners need to be careful that the tooling they introduce to address this list doesn’t hinder the business or actually increase the attack surface further in other ways.”