Kubernetes Security Fundamentals: The Misconfigurations That Actually Bite In Production

TL;DR

• The Kubernetes misconfigurations that account for the most breaches in production are identity and access management (IAM) and role-based access control (RBAC), broken object-level authorization (BOLA), infrastructure-as-code (IaC) mistakes,  cluster and workload misconfigurations, insecure defaults, poor network security, lack of oversight, exposed platform vulnerabilities, and secrets exposure.
• Kubernetes must be secured at the cloud, cluster, container, and code layers.
• It’s not just code vulnerabilities — misconfigurations account for a significant proportion of Kubernetes security incidents.
• Lack of visibility allows threats to persist in IaC configurations and images, making it to runtime where they can be exploited.
• Ownership of Kubernetes security must be taken for every layer, and misconfigurations should be protected against using automated tools that protect code and configurations across the entire software development lifecycle (SDLC).
• OX Cloud provides infrastructure and runtime analysis that helps ensure that Kubernetes security vulnerabilities and misconfigurations are traced to their source in a closed-loop approach.

Why Do Kubernetes Misconfigurations Still Reach Production? 

Kubernetes (K8s) is a versatile container orchestration platform that forms the foundation of many of the apps and services that power the internet and business processes. However, despite its popularity and ubiquity, and developers’ and *Ops teams’ awareness of established best practices, Kubernetes misconfigurations still frequently make it to production. And it can hurt.

This guide outlines the misconfigurations that systems builders, DevOps engineers, and CISOs should watch out for and the impact they have on Kubernetes security – from identity and access management (IAM) and broken object-level authorization (BOLA) issues, infrastructure, and infrastructure-as-code (IaC) mistakes that result in real attack paths. It then explains how visibility, responsibility, and proven AI-powered development and runtime security tools protect against these vulnerabilities.

Recap: The Four Layers of K8s Security (The Four Cs)

Kubernetes security can be split into four layers. These are known as the four Cs:

• Cloud: This is the hosting infrastructure your Kubernetes environment runs on. This may be on a cloud platform operating on a shared responsibility model, your own production servers, or a hybrid. Virtualized and physical servers, networks, managed services (storage, workers, etc.), and other cloud resources must be secured at this level. Threats at this level include weak IAM and network security. 
• Cluster: Kubernetes cluster security covers the control plane. This includes the kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and cloud-controller-manager components. These form the Kubernetes platform that provides the K8s API, manages the built-in key-value store, handles scheduling, runs the controller, and integrates with cloud providers. 
• Container: Kubernetes orchestrates containers that run images. These run on pods, which are distributed across physical nodes. Runtime security and isolation are container security best practices, as attackers may attempt to break out of containers to access your broader infrastructure. 
• Code: Within each container is your running app, service, or workload code. Supply chain attacks, insecure generated code, and compromised developer tools are just some ways your code can become an attack vector that allows attackers to exploit containers and turn them into stepping stones to your infrastructure and data.  

Misconfiguration at any of these levels can be catastrophic. For example, OX Research discovered CVE-2025-65719, which allows for full code execution when a user visits a malicious website, granting full access to the system and any Kubernetes clusters it has access to, as demonstrated in the short video below:

The affected kubectl MCP Server is heavily utilized in DevOps, creating an attack path to the cluster layer. While this was a software vulnerability in the client, any of the misconfigurations detailed below could assist an attacker in gaining further access to infrastructure, containers, workloads, and other services by exfiltrating secrets. 

Hardened configurations with scoped credentials for service accounts, on the other hand, would mitigate the potential damage by preventing lateral movement and restricting the actions an attacker could take. And it is, realistically, always a matter of time before an attack path is exploited. With automated AI-powered attack tools constantly scanning the internet for vulnerable systems, any misconfiguration poses a real risk. 

The Kubernetes Production Misconfigurations That Account for Most Breaches (And What to Do About Them) 

Identity and Access Management (IAM) and Role-Based Access Control (RBAC) Falling Short

Unauthorized access caused by overly permissive or misconfigured permissions is a threat at all layers. Attackers using stolen credentials or gaining remote code execution (RCE) can break containment and move laterally to exploit weaknesses that should not be reachable. IAM with least privilege, and automatically rotated, short-lived credentials (ideally single-use) help prevent access misconfigurations from being used as a stepping stone to the rest of your infrastructure and data. 

The importance of strong authentication is highlighted in CVE-2025-1974, where an attacker with access to the Kubernetes pod network can execute arbitrary code.

Broken Object Level Authorization (BOLA) 

BOLA occurs when an API fails to verify whether an authenticated user has authorization to access specific data. Even if IAM and RBAC are configured correctly with the intended role assignments, the code layer fails to make appropriate checks. This can be due to misconfiguration or a code bug that needs to be detected and fixed. AI vulnerability scanning is effective in identifying BOLA threats.

Infrastructure-as-Code (IaC) Mistakes

AI-driven IaC streamlines operations and reduces manual deployment tasks, but a single misconfiguration can proliferate across nodes and re-appear until it is noticed. AI-powered IaC evaluation tools can scan for misconfigurations to combat this risk at the cloud layer.

A major authentication provider suffered an outage in 2023, caused by production Kubernetes workers becoming unavailable due to an IaC mistake that propagated automatically.

Cluster misconfiguration

Kubernetes security issues at the cluster layer include misconfigured RBAC, allowing anonymous access, not enforcing encryption, and not keeping the Kubernetes control plane and worker nodes updated. Detecting these issues requires inventory tracking and runtime security that is built for ephemeral environments.

Even minor changes to cluster configurations can have cascading effects. For example, the Pi-Day Reddit outage in 2023 was caused by a Kubernetes misconfiguration when a Kubernetes update changed the terminology used to label nodes.

Workload Misconfiguration

Kubernetes is flexible and gives you a lot of room to make mistakes. Enabling namespace sharing, granting containers elevated privileges, and providing access to the host filesystem are all possible, but should only be implemented when necessary and with great care. As a result, container vulnerability scanning tools should perform pre-deployment configuration scanning to address this.

Namespace boundaries are important for Kubernetes security, as evidenced by CVE-2021-25740 in which the Kubernetes team specifically warns about the risks of cross-namespace forwarding.

Insecure Default Configurations

Across the cloud, cluster, container, and code layers, insecure defaults are a significant threat that can go unnoticed. 

Developers should be aware of the risks that default configurations pose and that they are usually only intended to get users up-and-running for local development quickly and easily, and are not intended for secure production use. Unsafe defaults should be identified and flagged as part of deployment pipelines along with other Kubernetes misconfigurations.

The Kubernetes Dashboard is a famous example of this: it was often accidentally exposed to the internet, and defaulted to using a service account with elevated privileges, potentially allowing attackers to gain full control of a cluster.

Network Security and Segmentation

If an attacker gains access to a single component or workload, freely accessible networks will allow them to move laterally across your infrastructure and reach your other assets, and potentially gain a permanent foothold. Network segmentation and security policies must be correctly configured to prevent intrusion and movement, to protect critical assets and data.

CVE-2021-25740 describes how a Kubernetes vulnerability could allow attackers to direct traffic to any IP address — something that would be prevented with sufficient network security policies.

Lack of Monitoring, Logging, and Scanning

Monitoring for suspicious activity at the cloud/network level, as well as on the control plane and within containers, can help identify and block exploits under active attack before they can have an impact. 

It can also pre-empt security issues, detecting supply chain risks and Kubernetes misconfigurations. For example, repeated failed login attempts from an external IP address may surface an unintentionally internet-facing service.

In 2018, Tesla suffered a cryptojacking incident to its Kubernetes infrastructure (caused by an exposed Kubernetes Dashboard) that went undetected by internal teams, most likely due to inadequate visibility.

Exposed Platform and API Vulnerabilities

If a vulnerability is not reachable through an attack path, it cannot be exploited. This is particularly important for zero-day attacks where the vulnerability is not known or identifiable in advance. Kubernetes security should focus on protecting as much of the infrastructure as possible, exposing only what is required.

For example, CVE-2024-21626 allowed attackers to break out of containers – but is rendered ineffective if attack paths are blocked by security controls such as image scanning, runtime monitoring, and node isolation. 

Secrets Exposure

This is the end goal as well as the beginning of new attacks. Leaked or stolen secrets such as API keys and service account credentials can lead to further intrusion, data breaches, and the stealing of cloud resources (running up your AWS bill, using up your AI token allowances, etc.). 

Preventing secrets exposure requires secrets detection that scans containers and delivery pipelines and identifies hard-coded secrets as early as possible.

Historically, Kubernetes stored secrets unencrypted in etcd – meaning they were readable to anyone who gained access to that component, and causing them to appear in backups, making them more difficult to track and secure. This is mitigated by ensuring encryption is enabled in the Kubernetes configuration.

Who’s Responsible for Kubernetes Security at Each Layer?

Responsibility for Kubernetes security will fall on different stakeholders depending on the layer. End-to-end coverage of the SDLC should involve responsibility from stakeholders at every level, with security tools that span them, so that context is not lost and gaps do not appear. 

Job roles and titles may differ or overlap depending on the size of your team – the key is that you identify an individual to be responsible for each component and stage of development and deployment, and leverage automation to ensure that risks are identified, communicated, and remediated.

Kubernetes Security Layer	Primary Ownership	Responsibilities
Cloud	CISO, DevOps	Cloud-native security, ensuring responsibilities are covered under a shared model
Cluster	DevOps, Security Team	Securing Kubernetes control plane, managing RBAC, secrets, and API configurations
Container	AppSec, DevOps	Securing container images, runtime security policies, and container runtime hardening
Code	Developers, AppSec	Writing secure code, integrating security with testing

Kubernetes misconfigurations are a pervasive, persistent threat that can be introduced at any time. Continuous protection is required, and the necessary sharing of responsibilities across different parts of the SDLC should not lead to silos. 

Centralized, automated analysis across both the application layer and cloud infrastructure maintains visibility and ties risks back to their source. It is up to the accountable party to make sure the best runtime security tools are chosen.

While misconfigurations and vulnerabilities are most visible in production, development and testing pipelines and environments cannot be overlooked, as OX discusses with Mario Duarte, CISO at Aembit/former CISO of Snowflake:

Static Application Security Testing (SAST) Is Not Enough in Distributed, Ephemeral Environments

Automated security tools don’t just streamline the processes involved in securing apps and avoiding Kubernetes misconfigurations; they are foundational to their feasibility and success in environments that scale up and down at an instant.

Historically, the primary tool is SAST. However, SAST has weaknesses and does not provide adequate protection on its own, especially in dynamic cloud environments:

• Runtime and dependency vulnerabilities are not detected
• Multistep vulnerabilities are not detected (especially in microservices-based architectures widely used with Kubernetes)
• Code lacks context, which can lead to false positives and noise that distracts from real issues
• The environment is not covered

To solve this, Static Application Security Testing (SAST) is often complemented by Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST), and penetration testing. Even with application security posture management (ASPM) to consolidate and link vulnerabilities, risks, and events can lead to fragmentation.

Noise and prioritization are also factors in complex, distributed Kubernetes environments. Visibility is a must, but it is important to make sure that you’re prioritizing misconfigurations and vulnerabilities that are actually reachable and exploitable. The proliferation of sophisticated AI attacks is also testing the capabilities of SAST.

Detect and Protect Against Kubernetes Misconfigurations in Real-Time With OX Cloud

AI is the future of development, deployment, and infrastructure management, but someone must be responsible when there’s a code flaw or configuration issue in deployment. The agility AI-driven development provides is negated if manual review is required for every update to app code, IaC, permissions, and configurations.

OX Cloud covers all four C’s of Kubernetes security and scans the hosting environment through cloud platform integrations with GCP, GKE, AWS, Azure Cloud, and Amazon EKS. This protection is continuous: new vulnerabilities and misconfigurations are detected when they emerge in development or production Kubernetes environments, providing real-time visibility into all layers using visualized attack paths.  

Once you have onboarded to OX and connected it to your source control and your cloud provider, OX Cloud will analyze your cloud infrastructure across all environments. It gains context across code repositories and pipelines, and checks for active Kubernetes misconfigurations as well as issues in IaC and templates. 

It can then take a holistic approach to analysis, generating an inventory of all cloud assets in a Cloud Bill of Materials (CBOM) and mapping them to their configurations, exposures, and vulnerabilities, identifying relationships between dependencies, and linking reachable and exploitable risks to their causes.

OX Cloud provides you with a closed-loop, unified toolchain and a single source of truth that closes visibility gaps in busy Kubernetes environments, allows for the clear assignment of responsibility, and helps you prioritize remediation – without slowing down AI-enhanced development and deployment workflows.

OX Cloud is one of the four pillars of OX AINAPP, the AI-Native Application Protection Platform. It works with OX VibeSec, OX Code, and OX Agentic Pentester to enable a strategic, context-aware approach to Kubernetes security.

Get started with OX for free, eliminate your fragmented legacy tools, and gain complete real-time visibility across your Kubernetes environments.