Kubernetes Security Best Practices: Hardening Build to Runtime

Kubernetes ships with permissive defaults, so cluster security is your job. Learn Kubernetes security best practices across build, deploy, and runtime phases.

What Is Kubernetes Security?

Kubernetes security is the set of controls you apply across build, deployment, and runtime to protect a cluster, the workloads it runs, and the pipeline that feeds it. Without them, one unauthenticated request can take over your entire cluster. That was IngressNightmare, the 9.8-severity flaw disclosed in March 2025 in ingress-nginx, the controller running in over 40% of Kubernetes clusters.

Its admission webhook sat on the pod network with no authentication, and ingress-nginx reads every Secret in the cluster by default. Reach the network, own the cluster. It took no exploit chain, no stolen password: just permissive defaults doing what they were configured to do.

That gap, between what Kubernetes ships with and what a production cluster needs, is what hardening closes. Kubernetes security best practices are how you close it, phase by phase, from the image you build to the workload you run. Because orchestration centralizes your workloads, secrets, and east-west traffic in one control plane, a single misconfiguration can expose every service you run, which is why that work falls to you rather than the platform.

Why is Kubernetes Security Important?

Kubernetes does not harden itself. The CISA/NSA Kubernetes Hardening Guidance documents three telling defaults on every new cluster: anonymous API server login is enabled, Secrets are stored unencrypted in etcd, and audit logging is turned off. The shared-responsibility model puts four controls in your hands: role-based access control (RBAC), network policy, secrets encryption, and runtime controls. The cloud provider will not configure them for you, and neither will the distribution. Because those controls live in your configuration and drift over time, teams increasingly verify them continuously with Kubernetes security posture management instead of auditing by hand.

An attacker who reaches an unauthenticated API server can read every Secret in etcd, schedule a pod on any node, and move between namespaces while audit logging stays silent, so the first signal you get may be the breach itself. One exposed endpoint becomes cluster-wide access in minutes, the same pattern IngressNightmare followed.

The stakes scale with adoption. The Cloud Native Computing Foundation (CNCF) Annual Cloud Native Survey reports that 82% of container users now run Kubernetes in production, up from 66% in 2023. As clusters sit in the path of customer-facing services, regulated data, and audit obligations, a single missed control turns into breach exposure, failed audits, and reportable incidents your team has to answer for. Knowing what is at stake only matters once you know which parts of the cluster carry that risk.

Core Components of a Kubernetes Cluster

You cannot harden what you have not inventoried. Each component carries a specific security exposure, and understanding that exposure tells you where your controls must apply.

Control plane components:

• API server: Every kubectl command you run, every admission webhook, and every service account token request passes through the API server. Unauthorized access here means full cluster control.
• etcd: Stores all cluster state, configuration, and Secrets you depend on. Read access to etcd is functionally equivalent to root on your entire cluster.
• Scheduler and controller manager: A compromised scheduler can place workloads on specific nodes to exploit local resources. Manipulation of controllers can alter deployments, replica counts, and resource assignments silently.

Worker node components:

• kubelet: The agent on every node that executes pod specs. If you leave the kubelet API exposed, an attacker can create containers or execute commands directly on the node.
• kube-proxy: Manages network rules for service routing. Misconfigured proxy rules can expose your internal services to external traffic.
• Container runtime: Executes containers on the host. A vulnerable runtime exposes every container it supports and the host itself, as NIST SP 800-190 notes.

Pods, containers, and networking:

• Pods share network namespaces, so a compromised container in a pod can access other containers in the same pod without network controls. Without NetworkPolicy objects, your pods in different namespaces communicate freely by default. 
• Container images and infrastructure-as-code (IaC) templates enter your cluster from external registries, and a poisoned image pulled into production propagates across every node that schedules it. Mapping each component to its exposure tells you exactly where the hardening controls in this guide apply.

How Kubernetes Security Works Across the Build-to-Runtime Lifecycle

You secure Kubernetes through a continuous workflow, not a point-in-time check. Each phase enforces a different category of control, and the output of one phase becomes the input for the next. Here is what happens at each step.

1. Build time: You scan container images for known vulnerabilities, validate IaC templates against policy, sign images cryptographically, and generate a software bill of materials (SBOM). These preventive controls stop problems at the source, before any artifact can be scheduled.
2. Deploy and configure: When you submit a workload, admission controllers evaluate it against policy before scheduling. RBAC determines who can create, modify, or read resources, and network policies define which pods can communicate. The image you signed at build is only protected here if admission control actually checks the signature.
3. Control plane and node configuration: You configure the API server, etcd, kubelet, and node OS to reduce what is exposed. Authentication, authorization, and encryption set the trust boundary every other phase relies on, so a weak control plane weakens everything downstream.
4. Runtime: Monitoring tools watch for behavioral anomalies, configuration drift, and known attack patterns in your running workloads, while seccomp and AppArmor profiles restrict what system calls your containers can make. Runtime is also where you catch the gaps that build and deploy missed.

You close the loop when runtime findings feed back into your build phase as updated images, updated IaC, and updated admission policy. The lifecycle only works when every handoff holds. Here is what one failed handoff costs.

Impact of a Compromised Kubernetes Cluster

When your cluster is compromised, the consequences extend well beyond a single workload.

• Lateral movement and blast radius: Your clusters run dozens to thousands of pods sharing network connectivity. An attacker who gains access to one of your pods can move laterally across namespaces and nodes when RBAC is overprivileged and network policies are absent.
• Secrets exposure: etcd holds your API keys, database credentials, TLS certificates, and service tokens. Because Secrets are unencrypted by default, an attacker with etcd read access can extract every credential in your cluster.
• Supply-chain propagation: A poisoned container image deployed through your continuous integration and continuous delivery (CI/CD) pipeline reaches every node that schedules it. In clusters running hundreds of replicas, a single compromised image can execute malicious code across your entire infrastructure within minutes.
• Workload and data compromise: Your production databases, customer-facing applications, and internal services run side by side. A breach in one workload can expose sensitive data, disrupt service availability, or establish persistence for future attacks.
• Compliance and regulatory exposure: If your clusters process payment data, health records, or government workloads, they fall under PCI DSS, HIPAA, FedRAMP, and SOC 2 requirements. A misconfigured cluster that fails an audit can result in operational shutdowns and financial penalties.

Hardening reduces the blast radius of any single compromise, shortens incident response timelines, and produces the audit evidence your compliance program requires. Achieving that in practice is harder than it sounds, for reasons specific to how Kubernetes runs.

Challenges in Securing Kubernetes

Kubernetes security is operationally hard, even for your most experienced team members. The platform's ephemerality, declarative configuration model, and distributed architecture create friction that static security tools were not built to handle.

• Ephemeral, constantly changing workloads: Pods are created, destroyed, and rescheduled continuously. A posture snapshot of your cluster at 9 a.m. may not reflect its state at 9:05 a.m.
• Visibility gaps into running containers: Containers share the host kernel but isolate their processes, filesystems, and network stacks. Standard host-based monitoring tools often lack the context to distinguish normal container behavior from malicious activity.
• Configuration complexity and drift: A production cluster involves hundreds of YAML manifests, RBAC bindings, and admission rules. Drift between what you declare in Git and what runs in your cluster introduces untracked exposure.
• Multi-cluster and multi-cloud sprawl: If you run clusters across Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), and on-premises environments, you must enforce consistent policy across different managed services, each with its own shared-responsibility boundary.
• Fragmented tooling: Image scanning, RBAC management, network policy enforcement, runtime monitoring, and compliance reporting often require separate tools with no shared data model. Alert correlation falls on you.
• Skills and organizational friction: The specialized skills are scarce, and the 2025 CNCF survey found that for the first time the leading barrier to cloud native adoption is organizational rather than technical: internal communication, team dynamics, and leadership alignment. Controls do not get applied because no one owns them.

These constraints shape both your tooling choices and your hiring priorities, and they explain why the same mistakes recur across clusters.

Common Kubernetes Security Mistakes

Specific operator anti-patterns create the exposures that attackers exploit. Identify and eliminate each of these in your clusters:

• Running privileged or root containers. Privileged containers bypass all Linux kernel isolation. A container running as root with allowPrivilegeEscalation: true can escape to the host.
• Granting cluster-admin or wildcard RBAC. Wildcard permissions (resources: ["*"], verbs: ["*"]) extend automatically to API resources that do not yet exist. The Kubernetes documentation labels this pattern "DO NOT USE."
• Leaving default-allow networking in place. Without NetworkPolicy objects, your pods in different namespaces communicate freely.
• Storing Secrets in plaintext manifests. Committing credentials to Git or passing them as environment variables exposes them in crash dumps, logs, and shell history.
• Skipping image and IaC scanning. Deploying unscanned images lets vulnerabilities reach production unchecked.
• Treating hardening as a one-time gate. A cluster hardened at bootstrap drifts as your teams add workloads and modify configurations. Without continuous enforcement, posture degrades.
• Ignoring node and control-plane configuration. Leaving anonymous API server login enabled, skipping etcd encryption, and omitting audit logging are default states that require your explicit remediation.

Each of these is correctable with the practices below. Treat them as a checklist of exposures to retire before scaling additional workloads onto the cluster.

Kubernetes Security Best Practices

These Kubernetes security best practices form the operational core of Kubernetes cluster hardening, organized by the same four lifecycle phases introduced above. Work through them in order, because each phase assumes the one before it holds.

Securing the Build Phase

1. Scan images for vulnerabilities before they reach a registry. Integrate container image scanning into your CI pipelines so vulnerable images never become deployable artifacts.
2. Use minimal or distroless base images. Distroless images contain only your application and its runtime dependencies, with no shell, package manager, or unnecessary binaries. Pin images to explicit version suffixes (e.g., gcr.io/distroless/static-debian13) and never use the latest tag.
3. Sign and verify images. Use Cosign or Notary to sign images in CI. Configure admission controllers to reject unsigned or unverified images at deploy time.
4. Scan IaC and Kubernetes manifests. Validate Terraform, Helm charts, and raw YAML against security policy before they reach your cluster.
5. Generate an SBOM for every image to establish provenance and support vulnerability tracking after deployment.
6. Keep secrets out of images. Never bake credentials, API keys, or certificates into container images or Dockerfiles.

These build-phase controls keep vulnerable and unsigned artifacts out of the pipeline before anything can run. An image that passes them is still only safe if the cluster admits it correctly, which is where deploy-time configuration takes over.

Hardening Cluster Configuration and Deployment

These Kubernetes RBAC best practices and network controls turn deploy-time policy into enforced guardrails.

1. Apply least-privilege RBAC. Create namespace-scoped Roles with explicit verbs and resource names. Eliminate wildcard grants. Restrict cluster-admin to break-glass use. Set automountServiceAccountToken: false on service accounts that do not need API access.

2. Enforce default-deny network policies. Apply a default-deny-all Netwenforce mode with the restrictedorkPolicy, both ingress and egress, to every namespace at bootstrap. Add explicit allow rules per workload, including a DNS egress exception on UDP port 53.

3. Enforce the Restricted Pod Security Standard. Use Pod Security Admission in enforce mode with the restricted level for production namespaces. This blocks privileged containers, requires runAsNonRoot, mandates seccomp profiles, and restricts volume types.

4. Add admission control with OPA Gatekeeper or Kyverno. Enforce readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, image registry allowlists, and capability drop-ALL policies. Use dryrun mode first to audit existing workloads before switching to deny.

5. Manage Secrets in an external store with etcd encryption at rest. Use the key management service (KMS) v2 provider for envelope encryption, and mount Secrets as volumes via the Secrets Store CSI Driver, which uses tmpfs so secret data never reaches node disk. Avoid passing Secrets as environment variables.

6. Set resource limits. Define CPU and memory requests and limits on every container to prevent resource exhaustion.

With deploy-time policy enforced, your workloads run under least privilege and default-deny networking. The trust those guardrails rely on still sits in the control plane and the nodes beneath them, so harden those next.

Protecting the Control Plane and Worker Nodes

The control plane is the one place where a single weak setting reaches everything else. Configure each of these, then verify them on a schedule rather than once at bootstrap.

Hardening step	What to configure	Source
API server access	Require strong authentication and mutual TLS; keep the API server off the public internet.	CIS Benchmark
Anonymous auth	Set --anonymous-auth=false	CISA/NSA guidance
Audit logging	Enable API audit, metric, application, and seccomp logs; aggregate them outside the cluster and alert on them	CISA/NSA guidance
etcd	Encrypt at rest, require mutual TLS, and isolate behind a firewall only API servers can reach	CIS Benchmark
kubelet	Restrict API access, disable read-only ports, apply node-level configurations	CIS Benchmark
Node baseline	Align control plane, etcd, and nodes to the CIS Kubernetes Benchmark for your release; scan on a continuous cadence	CIS Benchmark
Versions	Patch Kubernetes, node OS, and the container runtime on a regular cadence	—

With the control plane locked down and the nodes patched, the foundation holds. A live workload can still drift from its declared state or be attacked from the inside, and runtime controls are what catch that.

Runtime Security and Threat Detection

Strong Kubernetes runtime security catches what static controls cannot.

1. Monitor runtime behavior. Deploy a container-native runtime security tool that watches for anomalous syscalls, unexpected process execution, network connections, and file modifications. NIST SP 800-190 states that traditional intrusion prevention system (IPS) and web application firewall (WAF) tools do not provide suitable protection for containers.
2. Detect configuration drift. Compare running workloads against their declared state in Git. Flag containers that have diverged from their original image or configuration.
3. Apply seccomp and AppArmor or SELinux profiles. Use RuntimeDefault seccomp profiles at minimum. Roll out custom profiles on a subset of nodes first, then expand cluster-wide after validation.
4. Run read-only root filesystems and drop unnecessary capabilities. Set readOnlyRootFilesystem: true and capabilities: drop: [ALL] on every production container.
5. Enforce runAsNonRoot. Require runAsNonRoot: true in pod security contexts. Build images to execute as a non-root user at build time rather than relying solely on deployment-time overrides.
6. Enable autonomous response and continuous audit logging. Correlate runtime alerts with audit logs to reconstruct attack timelines. Feed findings back into build-time policy to close the loop.

Together, these four phases produce a continuously hardened cluster. Industry benchmarks describe what "configured correctly" looks like at each phase, and you should measure your cluster against them.

Kubernetes Security Standards and Compliance

Industry-recognized benchmarks operationalize the practices described above and provide the audit evidence your Kubernetes compliance program requires.

Standard	Scope	Relevance
CIS Kubernetes Benchmark	Control plane, etcd, worker nodes, policies	Recognized by PCI DSS, FedRAMP, SOC 2, FISMA, and the NIST National Checklist Program
CISA/NSA Kubernetes Hardening Guidance	Build, deploy, network, RBAC, logging, runtime	Authoritative government baseline for federal and critical infrastructure clusters
Pod Security Standards	Pod-level privilege restrictions across three tiers	Built-in Kubernetes enforcement mechanism; maps directly to CISA/NSA guidance Table I
NIST SP 800-190	Container lifecycle security	Maps container controls to NIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4, and others)

Now that Kubernetes is the default production platform, compliance frameworks increasingly treat Kubernetes-specific controls as a distinct audit domain rather than a subset of general infrastructure security. 

Platform-specific benchmarks, such as the CIS GKE Benchmark and the CIS OpenShift Benchmark, extend the general benchmark with managed-service-specific controls. Knowing the standards is the baseline. The harder question is where Kubernetes security is heading next.

Future Trends in Kubernetes Security

The controls you deploy today sit on shifting ground, and three trends are reshaping how teams approach Kubernetes security best practices.

1. AI workloads move the attack surface. As clusters become the default home for AI and machine-learning workloads, GPU scheduling, model artifacts, and large training datasets become new targets. Securing the data and model supply chain is becoming part of cluster hardening, not a separate concern.
2. Software supply-chain integrity becomes mandatory. SBOM generation, signed artifacts, and provenance attestation are shifting from optional maturity markers to baseline expectations in regulated industries and government procurement.
3. Autonomous runtime defense replaces manual triage. The volume and speed of cluster activity outpace human review. Behavioral AI that distinguishes normal from anomalous workload activity, and responds without waiting for an analyst, is moving from differentiator to default.

Each trend points the same direction: more automation earlier in the lifecycle and more autonomy at runtime, which is where platform tooling earns its place.

Strengthen Kubernetes Security with SentinelOne

The native Kubernetes controls this guide covers, RBAC, NetworkPolicy, Pod Security Standards, etcd encryption, and audit logging, form the foundation of cluster hardening. SentinelOne adds posture management, supply-chain scanning, K8s admission control, and runtime threat detection on top, each mapped to a weakness this guide names.

Singularity Cloud Security scans Kubernetes clusters before they ever run. Build-time scanning integrates directly with CI/CD pipelines, version control systems, and container registries. It checks for known vulnerabilities and more than 750 types of exposed secrets. The same scan covers infrastructure-ascode templates, including Terraform, Helm, CloudFormation, and Kubernetes YAML, to catch policy violations early. A Kubernetes Admission Controller acts as the final gatekeeper at the API server, blocking unauthorized or known-malicious images before they deploy.

Kubernetes Security Posture Management (KSPM) closes visibility gaps across the cluster. It builds a unified inventory across clusters, nodes, namespaces, and deployments, then surfaces overly permissive access and risky configurations. The Offensive Security Engine™ then simulates real-world attacks, confirming through Verified Exploit Paths™ which misconfigurations attackers can actually reach. Security teams prioritize what's exploitable instead of triaging every finding. The same rules engine powers the Admission Controller, so policy stays consistent from posture through deployment.

At runtime, Singularity Cloud Workload Security built on extended Berkeley Packet Filter (eBPF) detects anomalous behavior at machine speed. Automated responses kill malicious processes and quarantine infected files without waiting on an analyst. Graph Explorer visualizes relationships across the Kubernetes attack surface, so teams see exactly what's exposed. When runtime detection flags a malicious image, that finding feeds back to the Admission Controller automatically. The image is then blocked from every future deployment, turning one detection into a lasting policy. Purple AI brings natural-language threat hunting and event summaries to your cloud workload telemetry on one data lake, so analysts query in plain language instead of pivoting across tools.

See where your clusters are exposed in production. Request a SentinelOne demo to walk through Kubernetes posture management and runtime threat detection in your own environment.

Take A Tour

AI-powered cloud workload protection (CWPP) for servers, VMs, and containers, that detects and stops runtime threats in real time.

Key Takeaways

Kubernetes ships with permissive defaults that leave cluster security in your hands. The Kubernetes security best practices in this guide span four phases: image scanning and signing at build, RBAC and NetworkPolicy at deploy, etcd encryption and audit logging at the control plane, and behavioral monitoring at runtime. 

Align your configuration to the CIS Benchmark and CISA/NSA guidance, eliminate the common mistakes identified above, and close the loop by feeding runtime findings back into build-time policy. Get there and you stop guessing. You can point at any namespace on any day and show what is enforced, what drifted, and what you did about it.

FAQs

Which Kubernetes settings are insecure by default?

Three settings ship insecure on every new Kubernetes cluster. The CISA/NSA Kubernetes Hardening Guidance v1.2 documents them: anonymous API server login is enabled, Secrets are stored unencrypted in etcd, and audit logging is disabled. 

Pod-to-pod communication is unrestricted without NetworkPolicy objects. You must harden these yourself. Neither the cloud provider nor the Kubernetes distribution applies these controls for you under the shared-responsibility model.

What is the difference between Kubernetes security and container security?

Container security and Kubernetes security operate at different layers of the same stack. Container security focuses on the image and container instance: vulnerability scanning, runtime isolation, capability dropping, and host kernel protection. 

Kubernetes security spans both individual containers and the cluster around them, adding RBAC, admission control, network policy, etcd, and orchestration audit logging. Container security fits within the broader Kubernetes security discipline.

How do Pod Security Standards relate to the deprecated Pod Security Policies?

Pod Security Policies (PSPs) were deprecated in Kubernetes v1.21 and removed in v1.25. Pod Security Standards (PSS) define three policy tiers (Privileged, Baseline, Restricted) and are enforced by Pod Security Admission (PSA), a built-in admission controller that applies policy at the namespace level via labels. 

PSA graduated to stable in v1.25. If your cluster runs v1.25 or later and you have not configured PSA, you are operating without the pod-level enforcement layer.

Which compliance benchmarks apply to Kubernetes clusters?

Four primary compliance frameworks apply to Kubernetes clusters. The CIS Kubernetes Benchmark is recognized by PCI DSS, FedRAMP, SOC 2, and FISMA. The CISA/NSA Kubernetes Hardening Guidance serves as the government baseline. 

NIST SP 800-190 maps container controls to NIST SP 800-53 Rev 5 control families. Pod Security Standards provide the built-in enforcement mechanism that maps directly to the CISA/NSA guidance.

Do managed services like EKS, AKS, and GKE handle cluster security for you?

Managed Kubernetes services handle control plane availability, patching, and some infrastructure security. You still own RBAC policies, NetworkPolicy objects, Pod Security Admission, Secrets encryption, and runtime monitoring. 

The shared-responsibility model applies: the provider secures the control plane infrastructure, and you secure the workloads, configuration, and access controls. Platform-specific CIS Benchmarks document the additional controls you must apply on each managed service.