The kubeconfig was too open. One click and the wrong hands could own the cluster.

Kubernetes access must follow the principle of least privilege. That means every user, service account, and component should have only the permissions needed for its specific task—and nothing more. In practice, most clusters drift from this rule. Wide-open ClusterRoleBindings, unused ServiceAccounts with admin rights, and overly permissive RBAC policies are common. Each one is a breach path waiting to be exploited.

To enforce least privilege in Kubernetes, start with RBAC. Map roles directly to the smallest possible set of API operations. Avoid * verbs and blanket list or get permissions across all resources. Audit every binding. Remove accounts that no longer need access. Rotate credentials often.

Use Kubernetes namespaces to isolate workloads and permissions. Scope roles to namespaces when possible. Prevent cross-namespace escalation by locking down role bindings that grant cluster-wide power. ServiceAccounts should map to a single workload. If one pod needs get access to ConfigMaps, that permission should be granted only to its ServiceAccount, in its namespace, for that resource alone.

Enable audit logging. Review logs for permission use. Identify unused privileges and strip them. Test changes in staging before applying to production.

Consider integrating OPA Gatekeeper or Kyverno to enforce policies that codify least privilege. With policy-as-code, you can make sure every new role or binding meets your security baseline before it ever runs.

Securing Kubernetes access is not one fix—it’s a process. But each small cut to over-permission reduces attack surface and risk.

Want to see least privilege in action without the headaches? Deploy a secure cluster in minutes with hoop.dev and watch it run with the right access, automatically.