Kubernetes Security Essentials for Production

Kubernetes security is a stack, not a setting

Kubernetes does not fail closed. A default cluster will happily schedule a privileged container, let it talk to every other pod, mount a service account token that can read secrets, and pull an unsigned image from anywhere on the internet. None of that trips an alarm, because none of it is a misconfiguration in the eyes of the scheduler — it is the default.

Securing a production cluster means working through four distinct layers, each with its own controls and its own failure modes: the cluster (control plane and API server), the node (the host and kubelet), the workload (pods, their network reach, and the secrets they consume), and the supply chain (the images and build pipeline that put code into the cluster in the first place). A gap in any one layer undermines the others. Least-privilege RBAC does nothing if an attacker can reach the kubelet directly on the node; a signed image does nothing if the pod runs as root with the host filesystem mounted.

This is the model we use when we harden and run clusters for clients. Work through it in order, and verify each layer instead of assuming the platform did it for you.

Layer 1: The cluster and API server

Everything in Kubernetes is an API call, so the API server is the security boundary that matters most.

• RBAC, least privilege, and no wildcards. Kubernetes ships with RBAC enabled, but that is not the same as RBAC being tight. Audit for the two patterns that quietly grant everything: cluster-admin bindings on service accounts, and roles that use * for verbs or resources. Scope permissions to specific namespaces, specific resources, and specific verbs. A CI pipeline that deploys to one namespace does not need cluster-wide get secrets.
• Kill anonymous and over-broad access. Ensure anonymous authentication to the API server is disabled, and treat any binding to the system:authenticated or system:unauthenticated groups as a finding until proven necessary.
• Turn on audit logging. Without the audit log you cannot answer "who created this pod" after an incident. Ship it off-cluster to your log pipeline so it survives a compromise of the cluster itself.
• Protect etcd. The key-value store holds every secret in plaintext unless you configure encryption at rest. Enable it, restrict etcd to the control plane network, and require mutual TLS between components.

Layer 2: The node

Pods run on nodes, and a container escape lands the attacker on the host. The node is where a workload-level compromise becomes a cluster-level one.

• Lock down the kubelet. The kubelet exposes an API that, if left with anonymous access enabled or authorization set to AlwaysAllow, lets anyone who can reach the node execute commands in running containers. Require authentication and set authorization mode to Webhook.
• Use a minimal, patched host OS. A container-optimized or immutable distribution shrinks the attack surface and the patch burden. Keep the kernel and container runtime current — many escapes exploit runtime CVEs.
• Isolate sensitive workloads. Use taints, tolerations, and node pools so that internet-facing or multi-tenant workloads do not share a kernel with your most sensitive systems.

Layer 3: The workload

This is where day-to-day risk concentrates, and where three controls do most of the work.

Network policies

By default, every pod can reach every other pod across all namespaces. A single compromised front-end pod can then scan and pivot through the whole cluster. Network policies restore segmentation. Start from a default-deny posture per namespace, then explicitly allow only the flows each service needs — front-end to API, API to database, and nothing else. Remember that network policy requires a CNI plugin that enforces it, such as Calico or Cilium; applying a policy with a CNI that ignores it gives you a false sense of safety.

Pod Security Standards

The old PodSecurityPolicy is gone. The current mechanism is Pod Security Standards, enforced by the built-in Pod Security Admission controller at three levels: privileged, baseline, and restricted. Aim for restricted in production namespaces. It blocks the container behaviors that make escapes easy: running as root, privilege escalation, host namespace sharing, and mounting sensitive host paths. Enforce it at the namespace label so nothing schedules without meeting the bar, and require containers to set runAsNonRoot, drop all Linux capabilities, and use a read-only root filesystem wherever the app allows.

Secrets management

Kubernetes Secrets are only base64-encoded, not encrypted, unless you enable etcd encryption at rest — and even then, any pod with a broad service account can read them through the API. Reduce that blast radius: enable encryption at rest, scope RBAC so workloads see only their own secrets, and prefer an external secrets manager (a cloud KMS-backed store or Vault) synced in through a CSI driver so the material never lives statically in etcd. Disable service account token auto-mount on pods that never call the API.

Layer 4: The supply chain

Most of what runs in your cluster was written by someone else — base images, libraries, and third-party charts. That makes the build pipeline part of your attack surface.

• Scan every image for vulnerabilities in CI and again in a registry that re-scans as new CVEs are disclosed. A base image that was clean at build time is not clean six weeks later. This is continuous application security, not a one-time gate.
• Sign images and verify signatures at admission. Use Sigstore/cosign to sign images in the pipeline, then use an admission controller to reject any image that is unsigned or fails verification. That is what stops a swapped or poisoned image from ever being scheduled.
• Generate an SBOM for each build so that when the next widespread library vulnerability lands, you can answer "are we affected, and where" in minutes instead of days.
• Pin and mirror. Reference images by digest rather than a mutable tag like latest, and pull from a private registry rather than trusting public sources at deploy time.

Runtime detection

Prevention is never complete, so you also need to see what the cluster is doing while it runs. Runtime tools such as Falco or eBPF-based sensors watch for the behaviors that signal a live intrusion: a shell spawned inside a container, an unexpected outbound connection, a process reading a service account token, or a write to a path that should be read-only. Feed those detections into your security operations so a cluster alert is triaged next to the rest of your telemetry rather than sitting unseen in a dashboard. Detection without a response process is just more noise.

Benchmark against CIS

Do not grade your own homework from memory. The CIS Kubernetes Benchmark provides a concrete, versioned checklist for the control plane, etcd, the kubelet, and workload policies, and tools like kube-bench score a cluster against it automatically. Run it as part of your pipeline and on a schedule so configuration drift surfaces on its own. Pair that node-and-cluster benchmarking with continuous cloud security posture management across the managed control plane, IAM roles, and networking around the cluster — the pieces that live in your cloud account rather than inside Kubernetes.

A production hardening checklist

1. RBAC scoped to namespace, resource, and verb — zero wildcard or cluster-admin grants on service accounts.
2. API server anonymous auth off, audit logging on and shipped off-cluster.
3. etcd encrypted at rest and network-isolated.
4. Kubelet authentication required, authorization set to Webhook.
5. Default-deny network policies with an enforcing CNI.
6. Pod Security Standards at restricted, non-root, capabilities dropped.
7. Secrets from an external manager, token auto-mount disabled where unused.
8. Images scanned, signed, verified at admission, and referenced by digest.
9. Runtime detection wired into your SOC.
10. CIS Benchmark scored continuously.

Where to start

If you are shipping to Kubernetes faster than you are hardening it, start with an assessment: benchmark the cluster against CIS, map RBAC and network exposure, and close the supply-chain gaps first, because that is where attacker effort is lowest. intSignal designs, hardens, and monitors production Kubernetes as part of our cloud security practice — control-plane configuration, workload policy, image signing, and runtime detection tied into a managed SOC. Talk to our cloud team and we will pressure-test your clusters before an attacker does.