Securing Kubernetes: The Defaults Are Not Your Friend

Series: From Container to Cluster, Part 3 of 4

Parts 1 and 2 covered containers and the discipline of keeping them hardened in production. Now we go up a layer. Kubernetes is the system that runs your containers, and it is also the system that can undo every bit of hardening work you just did. A pristine, signed, minimal image scheduled by a misconfigured cluster is a pristine, signed, minimal foothold.

Kubernetes was built for flexibility first. Its defaults reflect that. Out of the box, a cluster is a flat, chatty, permissive environment that assumes everything inside it is friendly. Securing it means systematically reversing those assumptions. Here is where to focus, in the order attackers do.

The API server is the crown jewel

Everything in Kubernetes flows through the API server. Every deployment, every secret read, every node registration. Compromise the API server, or acquire credentials with broad API access, and you own the cluster. There is no meaningful blast radius discussion after that point.

That means the API server should never be reachable from networks that do not need it, its authentication should chain to your identity provider rather than to long-lived static credentials, and every request to it should be logged. Audit logging is not optional telemetry. It is the only record of who did what to your control plane, and if it is off, your incident response starts with archaeology instead of evidence.

RBAC: the permission sprawl you will definitely have

Kubernetes role-based access control is powerful and precise, which is exactly why real clusters end up with permission sprawl. Under deadline pressure, someone binds cluster-admin to a service account to make an error go away, and that binding outlives the deadline, the project, and sometimes the contractor who created it.

The discipline is boring and non-negotiable. Least privilege per subject. Namespaced roles over cluster roles. No wildcard verbs or resources. Service accounts scoped to their workload, with automounting of tokens disabled where the workload never talks to the API. And a periodic, automated review of who holds what, because RBAC drift is not a possibility. It is a schedule.

Pay particular attention to permissions that are quiet paths to escalation: the ability to create pods (which can mount host paths), read secrets cluster-wide, or modify webhooks. An account that can do those things is cluster-admin with extra steps.

The network is flat until you say otherwise

By default, every pod in a Kubernetes cluster can talk to every other pod. All namespaces, all workloads, all ports. The front-end web pod can open a connection to the database in another team's namespace, and nothing will object.

Network policies fix this, but only if you deploy them with a default-deny posture. Deny all traffic in a namespace, then explicitly allow the flows the applications actually require. It is the same zero trust principle your architecture documents already promise, applied at the pod level where lateral movement actually happens. An attacker who lands in a compromised container and finds default-deny everywhere has a much worse day than one who finds a flat network and a cluster's worth of internal services to enumerate.

Egress deserves equal attention and rarely gets it. A workload that has no business reaching the internet should be mechanically unable to. Command-and-control traffic does not care about your ingress rules.

Admission control: policy as a gate, not a document

We introduced admission control in Part 2 as the enforcement point for image provenance. It is broader than that. Admission is where the cluster evaluates every object before it exists and rejects the ones that violate policy.

No privileged pods. No host network or host path mounts outside an explicit allow list. No containers running as root. No images from unapproved registries. Required resource limits. Required labels for ownership and data classification. Every one of these becomes a rule the API server enforces mechanically, on every request, including the ones made at 0300 by an exhausted engineer with good intentions.

Pod Security Standards give you the baseline tiers. Policy engines give you the custom rules your environment needs on top. Either way, the principle holds: if a security requirement only exists in a document, it does not exist.

Secrets, nodes, and the stuff under the floor

Three more items that separate a hardened cluster from a default one.

Secrets. Kubernetes secrets are base64-encoded, not encrypted, unless you turn on encryption at rest for etcd. Turn it on. Better, integrate an external secrets manager so that secret material is injected at runtime, rotated centrally, and never lives in a manifest in a Git repo.

Nodes. The cluster is only as trustworthy as the machines it runs on. STIG-hardened host operating systems, minimal packages, kubelet authentication and authorization enabled, and read-only ports disabled. The kubelet is an API server in miniature, and attackers know it.

Upgrades. Kubernetes ships releases fast and ends support fast. A cluster three versions behind is running known vulnerabilities in its own control plane. Staying current is a security control, and it is the one most disconnected environments struggle with the most, because upgrading an airgapped cluster is a logistics problem as much as a technical one.

That last point is not a footnote. In DoD environments, the gap between "we know we should upgrade" and "we can execute the upgrade" is where cluster security actually decays. Which is exactly the problem the final post in this series takes on.

Where this series goes next

Everything above is achievable by a strong platform team, once, for one cluster. The hard part is doing it repeatably: every cluster, every enclave, every impact level, every disconnected site, with configurations that are provably identical and upgrades that actually happen. Part 4 is about automating the deployment of the infrastructure itself, because consistency at scale is not a staffing problem. It is an automation problem.

AlphaBravo engineers deploy and secure Kubernetes in connected, disconnected, and classified environments across the DoD. This is the work we do every day.