ServiceAccounts

ServiceAccounts are a Kubernetes resource that provides an identity for processes running in pods to interact with the Kubernetes API and other cluster resources. Each namespace contains a default service account named default, and pods run under a service account unless another is explicitly specified. A pod’s credentials are delivered to the container environment via a secret-mounted token, typically as part of a projected volume that also includes the cluster CA certificate and the namespace.

Service accounts are intended for non-human users, such as applications and controllers, rather than human operators. Access to cluster resources is governed by Role-based Access Control (RBAC). A service account is granted permissions by binding it to a Role or ClusterRole through a RoleBinding or ClusterRoleBinding. The scope of permissions can be restricted to a namespace or applied cluster-wide.

Management and usage: you can create a service account in a namespace, then specify it in a pod or deployment spec with spec.serviceAccountName. If a pod uses the default service account, it inherits that account’s permissions. Tokens associated with service accounts are typically short-lived and rotated; since newer designs, tokens may be projected into pods and rotated automatically to reduce exposure risk. Tokens are bound to the service account’s namespace but not to human users.

Security considerations include enforcing least privilege via RBAC, and disabling automatic token mounting when not needed. Service accounts should be used to isolate application permissions, and separate accounts should be used for different components to minimize blast radius.