Service Accounts¶
A service account provides an identity for processes that run in a Pod.
When you (a human) access the cluster (for example, using oc or kubectl), you are authenticated by the API server as a particular User Account, typically through your organization's identity provider. Processes in containers inside pods can also contact the API server. When they do, they are authenticated as a particular Service Account (for example, default).
User accounts are for humans. Service accounts are for processes, which run in pods.
User accounts are global: names are unique across the whole cluster. Service accounts are namespaced, and every namespace gets a default service account. What a service account may do is controlled with RBAC roles and role bindings. On OpenShift, the service account also decides which security context constraints a pod may use.
Service account tokens¶
Kubernetes mounts a short-lived, automatically rotated token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token, bound to that pod's lifetime. Since Kubernetes 1.24 (OpenShift 4.11), long-lived token Secrets are no longer created automatically for service accounts.
- To get a token for use outside the cluster, for example in a CI system, request a time-limited one with
oc create token <service_account_name>. - Only create a long-lived
kubernetes.io/service-account-tokenSecret, as shown in the example below, when a tool truly can't refresh tokens. Anyone who reads that Secret can act as the service account until the Secret is deleted. - If a pod doesn't need to call the Kubernetes API, set
automountServiceAccountToken: false.
Resources¶
References¶
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-service-account
containers:
- name: my-app
image: quay.io/nginx/nginx-unprivileged:1.29
ports:
- containerPort: 8080
apiVersion: v1
kind: Secret
metadata:
name: build-robot-secret
annotations:
kubernetes.io/service-account.name: my-service-account
type: kubernetes.io/service-account-token