Kubernetes access is built on trust. Yet that trust is often blind, brittle, and hard to verify. Most teams assume their cluster’s authentication and authorization process is airtight. They rarely test the perception of that trust against reality. And when perception and reality drift apart, risk slips in.
Access trust in Kubernetes means more than RBAC and service accounts. It is about how each identity—human or machine—gains entry, what it can do, and why it was granted in the first place. Engineers configure it once, then hope nothing drifts. But drift happens.
Perception of trust is tricky. Leadership might believe access is locked down because compliance checklists say so. Engineers might believe only certain people can run privileged pods. In practice, kubeconfig files float around. Service tokens live longer than intended. Network controls give false comfort.
Attackers don’t hack the cluster head-on. They exploit the gap between perceived and actual trust boundaries. A lingering kubeconfig on a laptop. A forgotten namespace with wildcard permissions. A stale role binding after a teammate leaves.