ServiceAccounts, Authentication, Authorization and SecurityContexts

Every request to the Kubernetes API server passes through three stages in order: authentication (who is making this request), authorization (is that identity allowed to do this — RBAC is the usual mechanism), and admission control (mutating and validating webhooks and built-in controllers that can still modify or reject an already-authorized request). Any stage can stop the request before it reaches etcd.

Every Pod runs as a ServiceAccount — the default one for its namespace if none is specified. How that identity's token reaches the Pod has changed: a long-lived, non-expiring token stored in an auto-created Secret used to be generated for every ServiceAccount automatically; since Kubernetes v1.24, that automatic Secret is no longer created by default. Instead, Pods get a short-lived, audience-bound token delivered through a projected volume — stable behavior since v1.22 — refreshed automatically before it expires.

A securityContext can be set at the Pod level (applies to every container) or the container level (overrides the Pod level for that one container, field by field). Useful fields: runAsUser sets the numeric UID a process runs as; runAsNonRoot: true doesn't pick a UID for you — it only refuses to start the container if the UID it would run as turns out to be root. allowPrivilegeEscalation: false blocks a process from gaining more privileges than its parent had. readOnlyRootFilesystem: true mounts the container's root filesystem read-only. capabilities.drop: ["ALL"], optionally followed by adding back only the specific Linux capabilities actually needed, is the least-privilege pattern for capabilities.

If a Pod never talks to the Kubernetes API at all, automountServiceAccountToken: false — set on the Pod or its ServiceAccount — stops a token from being mounted into it in the first place, removing a credential the Pod has no use for.