Kubernetes Security Fundamentals: What Actually Matters

Kubernetes is not insecure, but it is permissive out of the box. Pods can generally talk to each other, service accounts are mounted automatically, and containers frequently run with more capability than they need. Securing a cluster is largely a matter of deliberately closing defaults that exist for convenience.

The control plane is the crown jewel

Access to the API server is access to everything the cluster runs. Anyone who can create workloads can generally run code on nodes, and anyone who can read secrets can read every credential the cluster holds.

That makes API server exposure, authentication and RBAC the first things to get right. An API server reachable from the internet without strong authentication is a critical exposure, and cluster-admin handed out casually is functionally the same thing.

RBAC in practice

Avoid granting cluster-admin except where genuinely unavoidable, and know exactly who holds it.
Prefer namespace-scoped Roles over cluster-wide ClusterRoles when the workload only needs one namespace.
Treat secret-reading permission as privileged — it is frequently equivalent to holding the credentials themselves.
Watch for escalation-capable verbs: the ability to create workloads, modify role bindings, or create privileged pods can amount to cluster takeover.
Disable automatic service-account token mounting for workloads that never call the API, which is most of them.
Review bindings periodically; they accumulate as teams and applications change.

Flat pod networking means one compromise reaches everything

Networking is flat until you make it otherwise

By default, any pod can reach any other pod in the cluster. That means a single compromised workload — perhaps through an application vulnerability — has network reach to everything else running there.

Network policies fix this, but they require a CNI plugin that enforces them, and a policy that is not enforced provides false assurance. Start by applying a default-deny policy per namespace and then explicitly permitting the flows each workload genuinely needs. Restrict egress too: a workload that never needs to reach the internet should not be able to.

Workload hardening

Run as a non-root user, and set the filesystem read-only where the application permits it.
Drop all Linux capabilities and add back only what is required, which is usually nothing.
Refuse privileged containers, host networking, host PID access and host path mounts except in narrowly justified infrastructure cases.
Set resource requests and limits so a single workload cannot starve a node.
Enforce these rules with an admission controller so they are guaranteed rather than merely documented.
Scan images for known vulnerabilities and rebuild regularly — a base image pinned two years ago carries every vulnerability disclosed since.
Verify image provenance so only images from trusted registries can run.

RBAC and network policy do most of the heavy lifting

Secrets and supply chain

Kubernetes Secrets are base64-encoded, not encrypted, unless encryption at rest is explicitly configured. Anyone able to read them in the API or in etcd can read the values.

Enable encryption at rest, restrict who may read secrets, and consider an external secrets manager for higher-value credentials. Equally important is what you deploy: admission of unsigned images, unpinned tags and third-party charts with broad permissions are all supply-chain risks that bypass every runtime control.

Related from TechBiz Security

Sources & further reading

Frequently asked questions

Is Kubernetes insecure by default?

It is permissive by default rather than insecure. Pod-to-pod networking is open, service account tokens are mounted automatically, and workloads may run with unnecessary privilege. Security comes from deliberately configuring the available controls.

What is the single most important Kubernetes control?

RBAC on the API server, because control-plane access is equivalent to control of everything the cluster runs. Network policy is a close second, since default flat networking lets one compromised pod reach every other workload.

Are Kubernetes Secrets encrypted?

Not by default — they are base64-encoded, which is encoding rather than encryption. Encryption at rest must be explicitly enabled, and access to read secrets should be treated as equivalent to holding the credentials.

Do network policies work everywhere?

Only when the cluster runs a CNI plugin that enforces them. Applying network policies on a cluster whose networking plugin ignores them creates false confidence, so enforcement should be verified by testing that blocked traffic is genuinely blocked.