July 6, 2026
Day 6: Who Are You, and What Can You Do? Kubernetes Auth, Demystified
Every command you run against a cluster goes through one door: the API server. So the first real question in Kubernetes security isn’t “how…

By UnixSingh
1 min read
Every command you run against a cluster goes through one door: the API server. So the first real question in Kubernetes security isn't "how do I stop attackers", it's simpler and sharper. Who are you, and what are you allowed to do?
This is the groundwork the rest of cluster security stands on. If the front door is weak, nothing behind it matters.
Zoom out first. Locking down a cluster is layers inside layers. The hosts need ordinary server hygiene (no root login, keys not passwords), because if someone owns the node, they own everything scheduled on it. The API server sits behind two gates: authentication, then authorisation. The components talk to each other over TLS. And inside the cluster, pods can reach each other freely by default, which is where network policies come in.
Here's the bit that surprised me: Kubernetes doesn't manage human users at all. There's no kubectl create user. For people it leans entirely on something external, a credential file, client certificates, or an identity provider like LDAP or Kerberos. What it does manage natively is service accounts, the identities apps and automation use. Same API server checking both, different origins.
The simplest way to see authentication working is a static credential file, a plain CSV of password, username, user ID and group, handed to the API server with a flag. It's a great mental model and a terrible production choice: plaintext creds on the control plane, nothing rotating, one file read from disaster.
Which sets up the real question. If plaintext files are a trap and non-expiring tokens are worse, how does a modern cluster actually hand identity to a running pod, and what changed so dramatically in Kubernetes 1.22 and 1.24 that it's the first thing I'd check on a cluster I inherit?
That's the second half of the write-up: service accounts, default-token auto-mounting, and the bound-token shift that makes older clusters quietly risky.
👉 Read the full breakdown on unixsingh.com: https://unixsingh.com/posts/k8s-day-6-security-primitives-authentication
Tags: Kubernetes, Cybersecurity, DevSecOps, Cloud Security, Information Security