What Is Kubernetes Security?

Kubernetes security concerns the orchestration layer rather than the containers it schedules — the control plane, the permission model, the network behaviour between workloads and the admission decisions made at deployment time. Container hardening is covered in container security.

The most important thing to understand about it is that the defaults are permissive. Kubernetes was designed for flexibility, and an unmodified cluster allows almost everything: every pod can talk to every other pod, service accounts are mounted automatically, and nothing prevents a workload requesting elevated privileges.

Three defaults worth changing immediately

Flat pod networking. By default any pod can reach any other pod in the cluster. Network policies change that to explicit allow-listing, and without them a single compromised workload has unrestricted lateral movement across everything running.

Automatic service account mounting. Pods receive a token whether or not they need one, and that token is a credential to the API server. Disabling it where the workload does not call the API removes a ready-made escalation path.

Unrestricted admission. Without admission controls, a deployment manifest requesting privileged execution, host networking or a host path mount will simply be accepted. Admission policy is where those requests get refused.

Role-based access control drifts quietly

Cluster permissions accumulate. A role is widened to unblock a deployment, a service account is granted cluster-wide read to make a dashboard work, and nobody revisits either. The result is a cluster where a number of workloads hold far more authority than their function requires.

Reviewing who holds cluster-admin, and which service accounts have cluster-wide permissions, is a short exercise that consistently finds something. It is worth scheduling rather than waiting for an assessment to raise it.

The control plane itself deserves separate attention. An exposed or weakly authenticated API server is a complete compromise of everything the cluster runs, and the same applies to the key-value store behind it, which holds every secret in the cluster.

Multi-tenancy is harder than it looks

Namespaces are an organisational boundary, not a security one. They separate names and provide a scope for policy; they do not by themselves prevent a workload in one namespace affecting another, and treating them as isolation is a common and consequential mistake.

Genuine separation between tenants requires network policy denying cross-namespace traffic, resource quotas so one tenant cannot starve others, admission policy preventing privileged workloads, and role bindings scoped per namespace rather than cluster-wide. Even then, tenants share a kernel.

Where the tenants are genuinely untrusted — different customers, or environments with materially different risk — separate clusters remain the defensible answer. Shared clusters suit teams inside one trust boundary; they do not suit isolation requirements that would matter in a breach.

Audit logging on the API server is the other item worth confirming early. It is not always enabled by default, it is the only record of who asked the cluster to do what, and without it an investigation into a cluster compromise has essentially no primary evidence to work from.

Where to start

Determine whether network policies exist at all. A cluster with none has unrestricted internal movement, which makes every other control considerably less effective, and introducing a default-deny policy namespace by namespace is tractable work.

See container security in practice. GuardsArm delivers cloud security assessment.