Kubernetes ServiceAccounts: Identity for Pods

WHY IT EXISTS Humans aren't the only ones who need to interact with a Kubernetes cluster. Applications running inside Pods, like custom controllers or monitoring tools, also need a way to securely authenticate to the Kubernetes API server. ServiceAccounts were created to provide this machine-level, in-cluster identity.

THE MENTAL MODEL Think of a ServiceAccount as a corporate ID badge for your application. A human engineer has a user account to log in. A robot on the factory floor (your Pod) needs its own machine identity to access secured areas (the Kubernetes API). The ServiceAccount provides a token—the badge—that the Pod can present to the API server to prove its identity and access rights.

HOW IT WORKS When a Pod is created, it's associated with a ServiceAccount (by default, the default ServiceAccount in the namespace). Kubernetes automatically creates a secret containing a JSON Web Token (JWT) and mounts it into the Pod's filesystem at a well-known location: /var/run/secrets/kubernetes.io/serviceaccount/. An application inside the Pod can read this token and use it as a Bearer token in the Authorization header of its API requests. The API server validates this token to authenticate the Pod's request and then uses Role-Based Access Control (RBAC) to authorize it.

WHEN TO USE IT Use a custom ServiceAccount whenever a Pod needs to programmatically interact with the Kubernetes API. This is essential for applications like custom controllers that watch for resource changes, monitoring agents that need to discover other services, or any application that needs to dynamically read Kubernetes Secrets or ConfigMaps.

WHEN NOT TO USE IT If your application is self-contained and never communicates with the Kubernetes API, you don't need to configure a custom ServiceAccount. A simple web server serving static content is a good example. ServiceAccounts are for in-cluster processes; they are not the right tool for authenticating external users or systems.

ONE CANONICAL EXAMPLE To give a metrics-scraper Pod permission to list all Pods in its namespace, you would do four things: first, create a ServiceAccount named metrics-scraper-sa. Second, create a Role that grants get and list permissions on the pods resource. Third, create a RoleBinding to link that Role to the metrics-scraper-sa ServiceAccount. Finally, you specify serviceAccountName: metrics-scraper-sa in your Pod's manifest. This ensures only that Pod gets the specific permissions it needs, following the principle of least privilege.