OWASP Kubernetes Top 10 2025: Cluster Risks and Security Controls

The OWASP Kubernetes Top 10 2025 is a prioritized list of security risks across Kubernetes workloads, authorization, secrets, admission policy, networking, exposed components, cluster software, cloud integration, authentication, and monitoring. It updates the project’s 2022 list and separates several risks that previously shared categories.

The official OWASP Kubernetes Top Ten identifies the 2025 list as available for feedback. Its ordering is a prioritization aid, not a measurement of every cluster. Architecture, hosting model, tenant boundaries, workload sensitivity, and cloud permissions change the impact of each entry.

Kubernetes security spans application manifests, cluster configuration, cloud infrastructure, identities, network controls, images, and runtime operations. A hardened Pod can still inherit a powerful service account, and strict RBAC can still be bypassed through an exposed component or cloud role.

Key Takeaways

• Harden workload defaults with non-root execution, dropped capabilities, restricted privilege escalation, seccomp, read-only filesystems, and resource limits.
• Give users and service accounts narrow RBAC permissions, then test escalation through role creation, workload changes, and token access.
• Enforce policy, network boundaries, secret handling, component exposure, and cloud trust at the cluster level rather than relying on developer memory.
• Collect Kubernetes audit, workload, identity, network, admission, cloud, and control-plane evidence in one investigation path.

What Changed in the Kubernetes Top 10 2025

Insecure Workload Configurations remains K01. Overly Permissive Authorization Configurations moves to K02 and broadens the earlier RBAC wording. Secrets Management Failures rises to K03, while Lack of Cluster Level Policy Enforcement and Missing Network Segmentation Controls follow.

The 2025 list separates Overly Exposed Kubernetes Components from Misconfigured and Vulnerable Cluster Components. It also adds Cluster to Cloud Lateral Movement as K08, reflecting the access a compromised workload may obtain through node or workload cloud identities. Authentication and logging complete the list.

Supply chain risk no longer appears as its own 2025 category, but it remains relevant through images, admission, cluster components, and deployment systems. Teams should still use software supply chain controls beside this list.

OWASP Kubernetes Top 10 2025 Risks Explained

K01: Insecure workload configurations

Kubernetes favors flexible defaults, and many are not sufficient for a hostile production environment. Containers may run as root, retain Linux capabilities, mount service account tokens, write to their root filesystem, lack resource limits, or run without the runtime’s default seccomp profile.

Set runAsNonRoot, drop capabilities, disable privilege escalation, use RuntimeDefault seccomp, and make the root filesystem read-only where the application permits it. Avoid privileged containers and host namespaces, add CPU and memory limits, and set automountServiceAccountToken: false when a workload does not call the Kubernetes API.

K02: Overly permissive authorization configurations

Kubernetes RBAC can grant broad verbs, wildcard resources, secrets access, role creation, Pod execution, or workload modification. Some permissions allow indirect escalation because a caller who creates a Pod can mount service account tokens or access node resources.

Design roles around exact tasks and namespaces, avoid wildcards, and separate human administration from workload access. Review aggregated roles and bindings, test impersonation where supported, and analyze escalation paths rather than reading each permission in isolation. Remove access when teams, workloads, and automation change.

K03: Secrets management failures

Kubernetes Secrets are base64-encoded objects, not automatically protected from every cluster reader or storage path. Secrets can leak through manifests, environment variables, logs, shell history, copied namespaces, backups, Git repositories, and excessive API access.

Enable encryption at rest with protected keys, restrict Secret read permissions, and avoid committing secret values. Use a managed secret provider or workload identity where appropriate, rotate credentials, and audit access. Prefer mounted files over environment variables when process and diagnostic behavior makes environment exposure harder to control.

K04: Lack of cluster level policy enforcement

Secure conventions fail when each team must remember every setting. Without admission policy, a new manifest can create a privileged Pod, public service, host mount, unsafe image, or unapproved registry even if documentation says otherwise.

Use Pod Security Admission and an admission policy engine for organization-specific rules. Apply policy to every relevant namespace, protect exceptions with ownership and expiry, and test enforcement during upgrades. Run policy checks in CI for fast feedback, while the cluster remains the final authority.

K05: Missing network segmentation controls

Flat cluster networking lets a compromised workload scan and contact unrelated services, control-plane endpoints, metadata services, and data stores. A NetworkPolicy has effect only when the installed network implementation enforces it.

Start with default-deny ingress and egress, then permit required flows by stable workload identity and namespace. Restrict DNS and external destinations, protect management endpoints, and test policy from running Pods. Coordinate cluster policy with cloud firewalls, service meshes, and host networking.

K06: Overly exposed Kubernetes components

API servers, dashboards, kubelets, metrics endpoints, etcd, ingress controllers, and administrative interfaces may be reachable from networks that do not need them. Even authenticated exposure increases credential attack and vulnerability reach.

Place control-plane and node interfaces on restricted networks, require strong authentication, and remove anonymous or legacy access. Inventory public and internal endpoints from the network, cloud load balancers, DNS, and service configuration. Limit dashboards and proxy functions that can relay privileged requests.

K07: Misconfigured and vulnerable cluster components

The API server, scheduler, controller manager, kubelet, etcd, container runtime, ingress controller, CNI, CSI, operators, and add-ons all have versions and security settings. An outdated or unsafe component can affect the entire cluster.

Use supported Kubernetes versions, follow provider or distribution hardening guidance, and maintain an upgrade schedule. Inventory add-ons and operators, restrict their service accounts, and patch exposed components quickly. Review configuration after upgrades because defaults and deprecated options change.

K08: Cluster to cloud lateral movement

Pods may reach cloud metadata services, node instance credentials, workload identity endpoints, or mounted tokens. A compromised container can use those credentials to access storage, secrets, databases, or infrastructure outside Kubernetes.

Use workload-specific cloud identities with precise trust conditions and permissions. Prevent Pods from using node credentials, restrict metadata access, and separate node roles from application roles. Monitor token exchange and cloud API activity with the Kubernetes namespace, service account, Pod, and workload owner attached.

K09: Broken authentication mechanisms

Cluster authentication can fail through shared certificates, static tokens, long-lived kubeconfigs, weak external identity integration, anonymous access, or service account tokens used outside their intended audience. Authentication proves identity but does not limit what that identity may do.

Use an external identity provider for people, short sessions, individual accounts, and strong administrator authentication. Rotate and revoke credentials, disable legacy methods, validate service account audiences, and protect kubeconfig files. Pair authentication tests with RBAC and admission tests.

K10: Inadequate logging and monitoring

Workload logs alone do not show changes to roles, Secrets, admission decisions, exec sessions, deleted resources, or control-plane requests. Cloud logs alone may show an API call without the Pod and service account that obtained the credential.

Enable Kubernetes audit logging at a useful policy level and collect control-plane, admission, identity, network, node, workload, and cloud events. Protect logs from cluster administrators who should not erase evidence, synchronize time, and test alerts. Retain enough object and request context for investigation without recording secret values.

Secure Workload Defaults Need Cluster Enforcement

The official K01 guidance calls out root execution, default capabilities, service account token mounting, seccomp, missing resource limits, privileged containers, and host namespaces. These are repeatable configuration conditions, which makes them suitable for admission checks.

Create a small baseline that most applications can meet without exceptions. Provide reviewed patterns for workloads that need writable storage, network administration, device access, or host integration. Exceptions should name the owner, workload, reason, compensating controls, and expiry date.

Policy rollout should begin in audit or warning mode where production safety requires it, then move to enforcement on a schedule. Measure denied and exempted resources so teams can see whether the baseline is reducing risk or simply producing permanent bypasses.

Kubernetes RBAC Review Must Include Escalation Paths

A role that cannot read Secrets may still create a Pod using a powerful service account. Permission to update a deployment can replace its image or command and inherit mounted credentials. Permission to create or bind roles can grant new access directly.

Build an escalation graph across verbs, resources, namespaces, service accounts, admission exceptions, node access, and cloud identities. Review both explicit bindings and paths created by workload control. Test important paths with real authorization checks in a non-production environment.

Workload identities should be unique enough for attribution and lifecycle management. Reusing one Kubernetes ServiceAccount across unrelated applications combines permissions and makes audit harder. The non-human identity security article covers ownership, reuse, credentials, and offboarding.

How to Test a Kubernetes Environment

Review manifests and rendered deployment output, then inspect live cluster state. Helm values, operators, mutation webhooks, and platform defaults can make the running object different from source. Compare both views with admission and security baselines.

Test from compromised-workload assumptions. Attempt Kubernetes API access, metadata access, network discovery, secret retrieval, namespace escape paths, cloud token exchange, and calls to management components from an ordinary Pod. Verify that default policies contain the workload.

Exercise operational failure and detection. Revoke a service account, deny a network path, rotate a secret, fail an admission webhook, and simulate an unauthorized role binding. Confirm that systems fail safely and that alerts connect the change with the responsible identity and workload.

Kubernetes Top 10 and Other Security Guides Overlap

Kubernetes runs applications, so the web and API Top 10 lists still apply to the deployed code. Cloud security guidance covers storage, identity, networking, and control planes outside the cluster. Supply chain frameworks cover images, packages, builds, registries, and provenance.

Use the Kubernetes list to focus on orchestration and cluster-specific paths. Map shared controls once, such as workload identity and audit, then test their behavior at each boundary. A single control label should not hide different enforcement in Kubernetes RBAC and a cloud IAM policy.

Frequently Asked Questions

What is the latest OWASP Kubernetes Top 10 version?

The OWASP project currently publishes the Kubernetes Top 10 risks for 2025. It updates the earlier 2022 list and changes several categories and positions. Reports should include the year because the K-numbers differ between editions.

Does Kubernetes enable secure workload defaults automatically?

Kubernetes provides security controls, but several workload defaults favor compatibility and ease of deployment. Teams need to set security contexts, resource limits, token mounting, admission policy, and network restrictions explicitly. Managed services reduce control-plane work but do not secure every workload or permission.

Is Kubernetes RBAC enough to enforce least privilege?

RBAC controls Kubernetes API actions, but workloads may also access cloud APIs, databases, networks, and application services. Admission, network policy, cloud IAM, secret policy, and application authorization cover other boundaries. RBAC review must also account for indirect escalation through workload and role changes.

Should Kubernetes Secrets be stored in Git?

Plain Secret manifests contain encoded rather than encrypted values and should not be committed with live credentials. Teams can use an external secret manager, sealed or encrypted configuration workflow, or deployment-time injection under controlled keys. Repository history and generated artifacts must also be checked for past exposure.