Service Accounts

In this lesson we’ll cover Kubernetes ServiceAccounts — the identities used by workloads and system components to authenticate with the Kubernetes API. You’ll learn what ServiceAccounts are, how tokens are provided to Pods, how to create and attach ServiceAccounts, how to disable automatic token mounting, and how to obtain tokens for external use. There are two account types in Kubernetes:

User accounts — for humans (cluster operators, developers).
Service accounts — for software (controllers, monitoring, CI/CD).

ServiceAccounts let applications authenticate to the API server. For example, Prometheus uses a ServiceAccount to scrape API metrics, and Jenkins may use one to create or modify resources.

A dark-background diagram showing two columns: "User" on the left with admin and developer role icons, and "Service" on the right with service icons including Prometheus and Jenkins. It illustrates user versus service accounts/roles-diagram.

Example scenario: my-kubernetes-dashboard

Suppose you build a small Python app called my-kubernetes-dashboard that queries the Kubernetes API to list Pods and display them in a UI. If the app runs in-cluster it should use a ServiceAccount to authenticate.

A ServiceAccount is an identity object in a namespace.
A ServiceAccount has an associated token which the app presents as a Bearer token when calling the API.
Think of the ServiceAccount as an ID card and the token as the barcode scanned to verify that ID.

A schematic diagram showing Kubernetes authentication: a token linked to a service account that accesses the kube‑api and a Kubernetes cluster, alongside a "My Kubernetes Dashboard" panel. The image illustrates how the dashboard communicates with the kube‑api to list running pods.

Default ServiceAccount and token mounting

Kubernetes automatically creates a default ServiceAccount in every namespace. When you create a Pod and do not specify a ServiceAccount, the Pod gets the default ServiceAccount. Kubernetes mounts the ServiceAccount token into the Pod at: /var/run/secrets/kubernetes.io/serviceaccount This is provided as a projected volume; the application can read the token file and use it to authenticate. Example: list ServiceAccounts in the current namespace:

$ kubectl get serviceaccount
NAME      SECRETS   AGE
default   1         218d

Describe a Pod to see the Service Account and the mounted path:

$ kubectl describe pod my-kubernetes-dashboard
Name:         my-kubernetes-dashboard
Namespace:    default
Priority:     0
Service Account: default
Node:         controlplane/192.168.96.172
Start Time:   Wed, 03 Sep 2025 16:30:28 +0000
Labels:
  name=web-dashboard
  pod-template-hash=5f88cdc488

Containers:
  web-dashboard:
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount

Volumes:
  kube-api-access-rtvkd:
    Type:                    Projected
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    Optional:                false
    DownwardAPI:             true

List files mounted into the ServiceAccount directory inside the Pod:

$ kubectl exec -it my-kubernetes-dashboard -- ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt   namespace   token

Table — files mounted into the ServiceAccount directory

File	Purpose
`token`	The ServiceAccount token (Bearer token) used to authenticate to the API.
`namespace`	The namespace in which the Pod is running.
`ca.crt`	Cluster CA certificate to validate the API server TLS certificate.

Creating a custom ServiceAccount

The default ServiceAccount has minimal privileges. For more controlled access, create a custom ServiceAccount and bind RBAC roles to it. Imperative creation:

$ kubectl create serviceaccount dashboard-sa
serviceaccount "dashboard-sa" created

Declarative YAML:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-sa
  namespace: default

Verify the new ServiceAccount:

$ kubectl get serviceaccount
NAME         SECRETS   AGE
default      1         218d
dashboard-sa 0         2s

Describe the ServiceAccount (note: newly created SA may show no mounted tokens until a Pod references it):

$ kubectl describe serviceaccount dashboard-sa
Name:                dashboard-sa
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

Bind RBAC roles (Role/ClusterRole + RoleBinding/ClusterRoleBinding) to grant the ServiceAccount the minimal permissions it needs. See Kubernetes RBAC documentation.

Attach a ServiceAccount to a Pod

To use a specific ServiceAccount, set serviceAccountName in the Pod spec: Pod manifest snippet:

apiVersion: v1
kind: Pod
metadata:
  name: my-kubernetes-dashboard
spec:
  containers:
  - name: my-kubernetes-dashboard
    image: my-kubernetes-dashboard
  serviceAccountName: dashboard-sa

After creating the Pod, confirm the association:

$ kubectl describe pod my-kubernetes-dashboard
Name:            my-kubernetes-dashboard
Namespace:       default
Service Account: dashboard-sa
...

Inside the Pod the token is mounted as before:

$ kubectl exec -it my-kubernetes-dashboard -- ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt   namespace   token

automountServiceAccountToken

By default, Kubernetes automatically creates and mounts tokens for ServiceAccounts and Pods. You can disable automatic token creation/mounting at either the ServiceAccount or Pod level.

Disable at the ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-sa
  namespace: default
automountServiceAccountToken: false

Or disable on an individual Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-kubernetes-dashboard
spec:
  automountServiceAccountToken: false
  containers:
  - name: my-kubernetes-dashboard
    image: my-kubernetes-dashboard
  serviceAccountName: dashboard-sa

When automountServiceAccountToken is false for the Pod (or for the associated ServiceAccount and not overridden), the token file will not be mounted into the Pod.

Using ServiceAccount tokens outside the cluster

Sometimes you need a ServiceAccount token for external tools (dashboards, CI/CD, monitoring). Use kubectl create token to generate a token for a ServiceAccount and print it to the console. By default tokens are short-lived (commonly 1 hour). Use --duration to request a longer token. Create a token:

$ kubectl create token dashboard-sa
eyJhbGciOiJSUzI1NiIsImtpZCI6Ij9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2UtYWNjb3VudCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkYXNoYm9hcmQtc2EiLCJhdWQiOlsic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRhc2hib2FyZC1zYSJdLCJleHAiOjE2OTU...

Create with a longer duration (example: 2 hours):

$ kubectl create token dashboard-sa --duration=2h
eyJhbGciOiJSUzI1NiIsImtpZCI6Ij9.eyJpc3MiOiJrdW...

You can decode the token (JWT header and payload) for inspection:

$ jq -R 'split(".") | .[0], .[1] | @base64d | fromjson' <<< 'eyJhbGciOiJSUz...'
{
  "alg": "RS256",
  "kid": "vOp_YvzJsnmxNV9uQ8zzs0LIHHa0n3Dy8O0v1EjXnSs"
}
{
  "aud": [
    "https://kubernetes.default.svc.cluster.local"
  ],
  "exp": 1664037763,
  "iat": 1664034163,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "default",
    "serviceaccount": {
      "name": "dashboard-sa",
      "uid": "7d0fdfe8-fbf3-4ff9-b362-d004297a73f6"
    }
  },
  "nbf": 1664034163,
  "sub": "system:serviceaccount:default:dashboard-sa"
}

Use the token as a Bearer token in API calls. Example:

$ curl --insecure --header "Authorization: Bearer eyJhbGciOiJSUz..." https://192.168.56.70:6443/api

Table — common kubectl ServiceAccount commands

Action	Command	Notes
Create ServiceAccount (imperative)	`kubectl create serviceaccount dashboard-sa`	Quick creation on the CLI
Create ServiceAccount (declarative)	Apply a YAML manifest with `kind: ServiceAccount`	Use in GitOps / manifests
Create token for SA	`kubectl create token dashboard-sa [--duration=2h]`	Use for external tools; tokens are short-lived by default
Disable auto-mounting	Set `automountServiceAccountToken: false` in SA or Pod spec	Prevents token file being mounted

Summary

ServiceAccounts are Kubernetes identities used by workloads to talk to the API server.
Tokens are associated with ServiceAccounts and presented as Bearer tokens.
Create ServiceAccounts imperatively (kubectl create serviceaccount) or declaratively with YAML.
Attach a ServiceAccount to a Pod using the serviceAccountName field.
Tokens are mounted into Pods at /var/run/secrets/kubernetes.io/serviceaccount by default; disable auto-mounting with automountServiceAccountToken: false.
For external tools (dashboards, CI/CD) use kubectl create token to generate a short-lived token; extend duration with --duration as needed.
Always follow least privilege: grant only the RBAC permissions necessary for the ServiceAccount.

By default, tokens created or auto-mounted are short-lived (often 1 hour). Use kubectl create token --duration=<value> to request a longer-lived token when needed. Always follow least-privilege practices and bind only the necessary RBAC roles to ServiceAccounts.

Links and references

That’s it for this lesson — practice these concepts on a cluster or in a playground to reinforce your understanding.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Example scenario: my-kubernetes-dashboard

Default ServiceAccount and token mounting

Creating a custom ServiceAccount

Attach a ServiceAccount to a Pod

automountServiceAccountToken

Using ServiceAccount tokens outside the cluster

Summary

Links and references

Watch Video

Practice Lab

​Example scenario: my-kubernetes-dashboard

​Default ServiceAccount and token mounting

​Creating a custom ServiceAccount

​Attach a ServiceAccount to a Pod

​automountServiceAccountToken

​Using ServiceAccount tokens outside the cluster

​Summary

​Links and references

Watch Video

Practice Lab

Example scenario: my-kubernetes-dashboard

Default ServiceAccount and token mounting

Creating a custom ServiceAccount

Attach a ServiceAccount to a Pod

automountServiceAccountToken

Using ServiceAccount tokens outside the cluster

Summary

Links and references