kubernetes-security

Kubernetes Security

Kubernetes ships permissive by default: any pod gets a service-account token mountable for API access, RBAC starts wide open until you constrain it, and nothing stops a container from running as root unless you tell it not to. Security here is subtractive work — removing default permissions the platform hands out for convenience, not adding a product on top.

Assume every pod will eventually be compromised and ask what that gets the attacker. The right default is the least the workload needs to function, enforced at admission, not caught in review.

1. Scope RBAC to the verb and resource, not the namespace

The most common RBAC mistake is binding ClusterRole: edit or cluster-admin because a narrower role was fiddly to write. A Role/ClusterRole should list exact verbs (get, list, watch, create) against exact resources — "can read Pods in this namespace" is a different, much smaller grant than "edit everything."

• Prefer Role+RoleBinding over ClusterRole+ClusterRoleBinding unless the permission genuinely spans namespaces — cluster-scoped grants are the ones that turn one compromised namespace into a cluster-wide incident.
• Audit with kubectl auth can-i --list --as=<sa> rather than reading YAML and hoping — it's the ground truth the API server actually enforces.
• Service accounts, not user credentials, should hold workload permissions; humans get scoped roles through your identity provider, see iam-access-management.

Done when: kubectl auth can-i --list for the workload's service account shows nothing beyond what it demonstrably calls.

2. Turn off the automount you didn't ask for

Every pod gets a service-account token mounted by default, whether or not it ever calls the Kubernetes API. That token is exactly what an attacker inside a compromised container reaches for first — disabling automount removes a capability most workloads never needed.

spec:
  automountServiceAccountToken: false   # set at pod or ServiceAccount level