Kubernetes Security Best Practices That Cut Breach Risk

Kubernetes security best practices are the controls that limit what an attacker can reach and change inside a cluster: least-privilege RBAC, network policies, Pod Security Admission, secrets kept out of Git, image scanning, audit logging, runtime threat detection, and regular upgrades. Each one addresses a different risk, so the order a team funds them in matters as much as the checklist itself.

The intrusions these controls guard against are rarely exotic. Google's H1 2026 Threat Horizons report covers a subset of Google Cloud activity from the second half of 2025. In that data, third-party software exploitation accounted for 44.5% of initial access, ahead of weak or absent credentials at 27.2% and misconfiguration at 21%. The checklist below covers each control, then sets an order of priority for the team that has to detect and respond inside the cluster.

TL;DR:

• Upstream Kubernetes lets pods talk to each other freely, and a self-managed cluster needs explicit configuration for Secret encryption and API audit logging, while managed services handle part of that for you.
• Enforcing RBAC and pod security at admission keeps them from drifting as deploys change bindings, which periodic access reviews struggle to catch.
• Once dangerous exposure is closed, runtime detection with a tuning owner, secrets moved out of Git, and network policies on real escalation paths are strong next projects for a small team.
• Image scanning and Center for Internet Security (CIS) benchmark scores work best as inventory inputs, because gating builds on raw CVE counts blocks deploys without removing much risk.
• The SOC can only investigate what the cluster records, so confirm audit and runtime coverage before writing detections against them.

What Kubernetes Security Covers

Kubernetes security is the practice of protecting a cluster's control plane, its nodes, and the workloads running on them. It also covers the identities, network paths, and secrets that connect them to the rest of a cloud environment. The discipline sits between infrastructure security and application security. The cloud provider or platform team secures the infrastructure, developers own the code inside containers, and the cluster's own configuration decides how far a compromise in either one can travel.

Workload-level tooling such as a cloud workload protection platform covers part of the runtime layer. Most of the controls below are ones a team configures in Kubernetes itself, in the API server, the admission chain, the network plugin, and the cluster's Secrets store.

Where Kubernetes Defaults Leave Gaps

In upstream Kubernetes, pods accept any traffic until a NetworkPolicy isolates them. Secrets are stored unencrypted in etcd unless encryption at rest is configured, and the API server records no audit events when no audit policy file is set. Managed services change some of these defaults. EKS, for example, applies envelope encryption to all Kubernetes API data on version 1.28 and later, but pod network isolation stays the customer's job on all three major managed services.

Managed clusters add exposure of their own: Datadog's cloud security research, updated in October 2025, found the managed API server exposed to the internet on 39% of EKS clusters, 34% of AKS clusters, and 54% of GKE clusters. Node identities carry cluster-to-cloud risk too: 13% of EKS clusters had a node role allowing administrator access, privilege escalation, broad data access, or lateral movement.

In a 2024 Red Hat survey of 600 professionals, 45% reported a runtime security incident in their container or Kubernetes environments in the previous 12 months. The 2025 OWASP Kubernetes Top 10 reads like the same list from the attacker's side, led by insecure workload configurations, overly permissive authorization, and secrets management failures.

Kubernetes Security Best Practices Checklist

The checklist runs in roughly the order a team configures a cluster, and each item covers what the control stops and where it tends to fail.

1. Enforce Least-Privilege RBAC at Deployment

Role-based access control decides what every user and service account can do through the Kubernetes API, and overly broad bindings are a documented route into clusters. In an April 2023 campaign Aqua tracked, attackers entered through an API server that gave anonymous users privileged access. They then created a ClusterRole with near-admin privileges and bound it to a new service account in kube-system, which kept them in the cluster even if anonymous access was later disabled.

Kubernetes' own guidance starts with least privilege. Grant only the permissions a workload needs, avoid wildcard verbs and resources, keep cluster-admin for break-glass use, and set automountServiceAccountToken to false where a pod never calls the API.

Periodic access reviews lag behind least privilege because bindings can change with any deployment. Policy-as-code checks in CI, repeated at admission with Kyverno, OPA Gatekeeper, or the built-in ValidatingAdmissionPolicy (stable since Kubernetes 1.30), stop an overprivileged binding before it reaches the cluster. Run new policies in audit mode first. An enforcing policy that rejects a legitimate deploy turns the policy engine into a production dependency, so it needs an owner and a rollback path.

2. Restrict Pod Traffic With Network Policies

Open pod-to-pod traffic lets a single compromised workload reach other services in the cluster. IngressNightmare, the ingress-nginx admission controller flaw tracked as CVE-2025-1974 and disclosed in March 2025, let any workload on the pod network exploit configuration injection. The Kubernetes project's interim mitigation was to switch the admission webhook off until clusters were upgraded. Datadog's remediation guidance adds keeping the webhook reachable only from the control plane, the kind of path a network policy can close.

NetworkPolicy objects only take effect when the cluster's network plugin (CNI) enforces them; without one, the API accepts a policy and nothing changes. The policies worth writing first follow observed traffic on escalation paths, such as admission webhook ports and egress from internet-facing namespaces. A default-deny egress policy also blocks DNS lookups until it explicitly allows traffic to the cluster DNS service, so test egress rules in staging before enforcing them.

3. Enforce Pod Security Standards With Pod Security Admission

Pod Security Admission is the built-in admission controller that replaced PodSecurityPolicy, which Kubernetes removed in version 1.25. It applies the Pod Security Standards per namespace at one of three cumulative levels: privileged, baseline, or restricted. Baseline disallows privileged containers and sharing host namespaces, and restricted adds requirements such as running as a non-root user and blocking privilege escalation.

Each namespace can apply a level in enforce, audit, or warn mode, which makes a staged rollout straightforward. Label namespaces to warn and audit at restricted, fix the workloads that trip it, and then enforce. The restricted level narrows configuration-based routes to privilege escalation and host access, though node kernel and container runtime patches still matter.

4. Keep Secrets Out of Git

Kubernetes stores Secret values as base64, an encoding that protects nothing, so anyone with get access to Secrets or read access to the pipeline that renders manifests can read them. Encryption at rest protects the copy in etcd, but credentials committed to Git are the larger exposure: GitGuardian counted 28.6 million new secrets in public GitHub commits in 2025 alone.

Two tools take credentials out of the repository. External Secrets Operator stores only references in Git and syncs the values from a vault or cloud secrets manager into Kubernetes Secret objects, which still need encryption at rest and tightly scoped read access. Workload identity removes static cloud keys altogether: pods get short-lived credentials from the provider's identity service through EKS Pod Identity or GKE Workload Identity Federation, so no static key exists to leak.

Both add operational work: workloads depend on External Secrets Operator having synced current values, and workload identity needs cluster-level configuration that a security team without cluster ownership has to request from the platform team. For the risk removed, they are still among the better trades on the list.

5. Scan, Verify, and Gate Images on Exploitable Findings

Image scanning finds known vulnerabilities in container images before they run, and it belongs in the build pipeline. Problems start when builds fail on raw counts of critical and high CVEs. In Datadog's 2026 study of tens of thousands of applications, 82% of vulnerabilities initially labeled critical could be downgraded once runtime exposure, exploitability, and reachability were weighed.

A gate built on raw severity counts blocks deploys over findings that are mostly not exploitable in that workload, and it invites workarounds. Block on whether a flaw can actually be reached and used in that workload, starting with known-exploited vulnerabilities in packages it loads. Track the rest with exceptions that expire, and route a known-exploited flaw with no fix to whoever owns the risk decision.

Signature verification covers the other half of the supply chain. The Kubernetes project recommends pinning images by digest or verifying their signatures at deploy time through admission control, which tools such as the Sigstore policy controller enforce.

6. Configure Audit Logging Before Writing Detections

The Kubernetes API server writes audit events only when an audit policy is configured. The policy decides what gets recorded, and backends such as log files or webhooks store it. On self-managed clusters that policy is a flag the platform team sets.

On managed services, the provider runs the API server and decides which audit logs are on by default. Several are opt-in, so checking them per cluster is an early step in cloud security monitoring for Kubernetes.

Confirm the events a detection depends on are recorded before writing it. A rule that looks for a new ClusterRoleBinding or a pod exec into kube-system returns an empty result that looks identical to a quiet cluster when the audit policy drops those requests.

7. Run Runtime Threat Detection With a Tuning Owner

Runtime detection watches what containers do after deployment: the processes they spawn, the files they touch, and the connections they open. Build-time controls and configuration scans cannot see this layer. Runtime signals work best alongside audit and cloud telemetry: MITRE's detection guidance for Deploy Container (T1610) pairs API-driven container creation with the process and network actions that follow it.

In December 2025, Sysdig documented the EtherRAT implant being deployed through React2Shell, a remote code execution flaw in React Server Components. It reported that runtime rules for suspicious commands run by a web server and for base64-encoded Python execution would trigger on the implant's behavior.

Runtime rules also need tuning, and Falco notes that its network rules often give the only definitive evidence of an attack but are hard to operationalize because of their potential for noise. Untuned rules piped straight into a SOC queue add to alert fatigue and train analysts to dismiss the alert that matters. Scope runtime detection as a detection engineering project with a named owner, a period where new rules run silently against live data, and a feedback loop for exceptions.

8. Patch and Upgrade on the Kubernetes Release Cycle

Kubernetes maintains release branches for the three most recent minor versions. Each gets about 12 months of standard support followed by two months of maintenance mode for critical fixes. As of late October 2026 that means 1.37, 1.36, and 1.35, and 1.34's end-of-life date is October 27, 2026. Many clusters fall behind that window: in the October 2024 dataset behind Wiz's 2025 Kubernetes report, 54% of clusters ran a supported version.

Upgrades cover more than the control plane. Node images, the container runtime, CNI plugins, and add-ons such as ingress controllers carry their own CVEs, and third-party software was the leading initial access vector in Google's Threat Horizons data.

Schedule each minor upgrade ahead of its end-of-life date, and track add-on versions in the same inventory as images. Add-ons reach end of life too: the Kubernetes project announced in November 2025 that it would retire ingress-nginx, ended best-effort maintenance in March 2026, and recommends migrating to Gateway API. Clusters still running it carry an ingress component that no longer gets security fixes.

How to Prioritize Kubernetes Security With Limited Engineering Time

The table weighs each control by the risk it addresses and what it costs to run.

‍

The right order depends on what a cluster already has. Close dangerous exposure first, such as a public API server, anonymous access, or an unpatched ingress controller, and confirm audit logging captures the events the SOC needs.

After those basics, a small team gets the most from runtime detection wired into the SOC's investigation flow, with its tuning weeks funded up front. It is the main control that sees in-container activity as it happens, while the others shrink the paths an attacker can use, and it only reduces harm when someone acts on what it finds. Getting credentials out of Git comes next, then network policies on the escalation paths that matter most. RBAC enforcement and Pod Security Admission follow as policy work matures.

Defer full CIS remediation on managed clusters, since it can produce findings the team cannot act on. The provider runs the control plane, and CIS publishes separate benchmarks for EKS, AKS, and GKE, including their more managed modes. Treat the score as inventory feeding the backlog.

The CIS benchmarks and the NSA and CISA hardening guidance for Kubernetes, last revised in August 2022, remain useful references for hardening breadth. They don't rank controls by exposure, and parts of the 2022 guide predate current Kubernetes versions.

What the SOC Needs From the Cluster

Kubernetes security usually splits by control type. The platform team owns preventive configuration: RBAC, admission policies, network policies, Pod Security Admission, and the CNI. The SOC, in-house or managed, owns detection and response on audit logs and runtime signals, plus the route back to the platform team when a finding needs a configuration change.

The split works when the SOC has the context to judge an alert: which deployment, team, and cloud identity sit behind a pod, and whether the behavior is normal for that service. A runtime alert on its own says a process misbehaved without saying which service or owner it belongs to, and investigating it without that context is often how cluster alerts end up closed as noise.

Containment needs the same preparation. Isolating a pod with a deny-all network policy, revoking a service account token, and rotating a secret each need a named approver in the incident response plan. Otherwise the first compromised workload is also the first time the team works out who can take it offline.

Frequently Asked Questions About Kubernetes Security Best Practices

What Are the 4 C's of Kubernetes Security?

The 4 C's are cloud, cluster, container, and code, a layered model in which each layer depends on the security of the one around it. Kubernetes now organizes its security controls by the CNCF's workload lifecycle phases of develop, distribute, deploy, and runtime.

How Do You Secure the Kubernetes API Server?

Restrict both network reach and permissions. Keep the endpoint private or restricted to allowlisted networks, authenticate users through the cloud provider's IAM or an OIDC identity provider, and authorize every request through RBAC. Kubernetes controls API access through authentication, authorization, and admission control, and each stage needs its own configuration.

Who Is Responsible for Kubernetes Security on EKS, AKS, or GKE?

Responsibility is shared. On EKS, AWS manages the control plane nodes and the etcd database, and the customer remains largely responsible for IAM, pod security, runtime security, network security, and the workloads themselves. Fully managed modes such as GKE Autopilot and EKS Auto Mode move more node management to the provider, but most cluster configuration stays with the customer.

Does a Service Mesh Improve Kubernetes Security?

It can. A mesh such as Istio adds mutual TLS between services, a strong identity for each workload, and authorization policies at the request level, beyond what NetworkPolicy enforces for layer 4 connections. It also adds a control plane, proxies, and certificate management to operate, so if encryption in transit is the only goal, compare that cost with what the CNI can already provide.

How Do You Harden Kubernetes Nodes?

Start with the kubelet, whose HTTPS endpoint treats requests that no other configured method rejects as anonymous by default. Run it with anonymous access disabled and authorization delegated to the API server in Webhook mode. Then enable the NodeRestriction admission plugin, which lets each kubelet modify only its own Node object and the pods bound to it, limiting what a compromised node's credentials can change elsewhere in the cluster.