Kubernetes adoption has moved fast, and security practices have, in a lot of organizations, not kept pace with that speed. Teams that would never dream of deploying a web server with default credentials will happily spin up a cluster with permissive default configurations left entirely unexamined, simply because Kubernetes security is more complex than traditional infrastructure security, and complexity tends to get deprioritized under deadline pressure. Here is where the real risk concentrates.<\/p>\n
Kubernetes Role-Based Access Control is powerful, but that power comes with real complexity, and misconfigured RBAC is consistently one of the most common security findings in cluster audits. Overly permissive service accounts, roles granting far more access than a workload needs, and default configurations left unreviewed – these create exactly the kind of privilege escalation paths that turn a single compromised container into full cluster access.<\/p>\n
The fix is not complicated in principle – apply the principle of least privilege deliberately, review RBAC configurations on a regular schedule, and avoid the common shortcut of granting cluster-admin access broadly just to unblock a deployment quickly. In practice, though, this requires ongoing discipline that easily slips once the initial cluster setup is complete and attention moves elsewhere.<\/p>\n
Container images frequently include vulnerable dependencies, and without automated scanning integrated directly into your CI\/CD pipeline, those vulnerabilities ride straight into production without anyone actively deciding to accept that risk. Base images update, and a container built from a now-outdated base image can accumulate known vulnerabilities over months without anyone noticing, since nothing about the running container visibly changes.<\/p>\n
Image scanning needs to be continuous, not an one-time check at build time. Vulnerabilities get discovered constantly in widely-used libraries, meaning an image that was clean when built can become vulnerable purely through the passage of time, with no code change on your end at all.<\/p>\n
By default, Kubernetes allows unrestricted network communication between all pods in a cluster – meaning a single compromised pod can potentially reach anywhere else in your entire environment. Network policies exist specifically to restrict this, but implementing them properly requires understanding your application’s actual traffic patterns, which is real work that is easy to defer indefinitely.<\/p>\n
Clusters running without network policies are, in effect, running flat networks – exactly the kind of architecture security teams spent the better part of the last decade moving traditional infrastructure away from. Skipping network segmentation in Kubernetes reintroduces precisely the risk that segmentation elsewhere in your infrastructure was meant to eliminate.<\/p>\n
Kubernetes Secrets look like a proper secrets management solution until you look closely – by default they are only base64-encoded, not encrypted, which means anyone with read access to the Secret object or to the underlying etcd datastore can trivially decode them. Etcd encryption at rest is available but not enabled by default in a lot of self-managed clusters, and even managed offerings vary in what they turn on out of the box. A surprising number of clusters run in production with database credentials and API keys sitting in etcd in a form that is one small permission slip away from being fully readable.<\/p>\n
The more durable fix is to stop treating native Secrets as the actual secrets store and instead pull credentials at runtime from a dedicated external system – HashiCorp Vault, AWS Secrets Manager, or a tool like Sealed Secrets or External Secrets Operator that keeps the sensitive material encrypted until the moment a pod actually needs it. This also solves the rotation problem that native Secrets handle poorly: rotating a credential stored as a plain Kubernetes Secret usually means a manual update and a pod restart, while a proper secrets manager can rotate on a schedule without anyone remembering to do it by hand.<\/p>\n
PodSecurityPolicy, the original built-in mechanism for restricting what a pod is allowed to do, was deprecated and removed from Kubernetes, and a fair number of clusters migrated off it without replacing it with anything equivalent – leaving pods free to run as root, mount the host filesystem, or run in privileged mode with no policy stopping them. The replacement is either the built-in Pod Security Admission controller or a policy engine like OPA Gatekeeper or Kyverno, both of which can enforce rules such as blocking privileged containers, requiring a read-only root filesystem, and disallowing host network access by default.<\/p>\n
The gap between clusters that migrated properly and clusters that just let the old policies quietly disappear is one of the more common findings in a cluster security review – and it is a gap that costs nothing to close technically, since the replacement tooling is free and well-documented. It mostly gets missed because nobody explicitly owns the follow-up task once the original deprecation notice scrolled past in a changelog.<\/p>\n
Even a perfectly configured cluster inherits risk from whatever images it pulls. Pulling base images directly from public registries without pinning a specific digest means the “same” image tag can silently change underneath you, and without image signing there is no cryptographic guarantee that what you are running is what you think you are running. Tools built on Sigstore, like cosign, let you sign images at build time and verify that signature at admission time, rejecting anything that was not built through your own trusted pipeline.<\/p>\n
Pairing that with a private registry that gates on vulnerability scan results – blocking images above a defined severity threshold from ever being deployable – closes a gap that network policies and RBAC alone cannot touch, because the problem in this case is not misuse of the cluster, it is trusting the wrong artifact to run inside it in the first place.<\/p>\n