Skip to main content

​
Concept and usage

Service accounts can be used to create a non-human identity (user equivalent) for processes and applications in Kubernetes.
A service account is a non-human account used by processes or applications running inside a pod to interact with the Kubernetes API server. It provides an identity for those processes. When you create a Pod without specifying a service account, it is automatically assigned the default service account in the same namespace.
ServiceAccountUser or group
LocationKubernetes API (ServiceAccount object)External
Access controlKubernetes RBAC or other authorization mechanismsKubernetes RBAC or other identity and access management mechanisms
Intended useWorkloads, automation, third-party applicationsPeople
Key behaviors:
  • Every namespace automatically gets a default service account.
  • When a pod is created, Kubernetes mounts the service account token as a volume at /var/run/secrets/kubernetes.io/serviceaccount. That path contains a token, ca.crt, and namespace file.
  • To prevent auto-mounting, set automountServiceAccountToken: false in the pod spec:
    pod.yaml
    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu
  automountServiceAccountToken: false
  • The default service account has limited permissions for basic Kubernetes API queries only.
  • To change the service account of an existing pod, you must delete and recreate the pod. For Deployments, editing the deployment will trigger a rolling update automatically.

​
Creating and using a service account

1

Create a service account

kubectl create serviceaccount <name-of-service-account>
kubectl create serviceaccount data-sa

kubectl get serviceaccounts
2

Generate a token for the service account

This token is used by the application to authenticate with the Kubernetes API server. By default, the token is valid for 1 hour.
kubectl create token data-sa
kubectl create token data-sa --duration=30m
3

Use the service account in a pod or API call

Authenticate with a bearer token directly:
curl https://<kube-apiserver>:6443/api --header "Authorization: Bearer <token>"
Or assign the service account to a pod. Kubernetes will auto-mount the token, so no manual token injection is needed:
pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu
  serviceAccountName: data-sa

​
Creating a long-lived API token

If you need a non-expiring token for a service account, create a Secret and associate it with the service account.
1

Create a service account

data-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: data-sa
This does not populate the secrets field (only auto-generated secrets do that).
2

Associate a secret with the service account

data-sa-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: data-sa-secret
  annotations:
    kubernetes.io/service-account.name: data-sa
type: kubernetes.io/service-account-token
3

View the secret token

kubectl get secret/data-sa-secret -o jsonpath='{.data.token}' | base64 -d

​
Adding imagePullSecrets to a service account

You can attach imagePullSecrets to a service account so that any pod using that service account can pull images from a private registry. Assuming you have a secret named my-registry with credentials for your private Docker registry: 
kubectl patch serviceaccount data-sa \
  -p '{"imagePullSecrets": [{"name": "my-registry"}]}'
Verify the imagePullSecrets are set for new pods using this service account: 
kubectl run nginx --image=nginx --serviceaccount=data-sa
kubectl get pod nginx -o jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'

Build docs developers (and LLMs) love

Get started for freeTalk to us