CKA Day 25: Kubernetes Service Account — RBAC Continued

Day 25/40 — Kubernetes Service Account: RBAC Continued

Overview

Day 25 of the 40-day CKA course explains Kubernetes ServiceAccounts — the identity mechanism for in-cluster workloads (Pods, controllers, CI/CD pipelines) that need to call the Kubernetes API server. Unlike human users authenticated via client certificates or OIDC, ServiceAccounts are “non-human” or “bot” identities managed entirely inside the cluster.

Key Concepts

What Is a ServiceAccount?

A ServiceAccount is a namespace-scoped Kubernetes object that provides an identity for processes running inside Pods. When a Pod needs to interact with the API server — to read ConfigMaps, list Pods, create Jobs, or query metrics — it authenticates as its assigned ServiceAccount.

The Default ServiceAccount

Every Namespace automatically contains a default ServiceAccount. If a Pod manifest does not specify spec.serviceAccountName, Kubernetes attaches the default ServiceAccount automatically.

The default ServiceAccount has no RBAC permissions beyond what the cluster’s default policies grant (typically minimal). This means:

• Pods using default can authenticate to the API server
• But they cannot read, list, or modify most resources unless a Role/RoleBinding explicitly grants them permission

Creating a ServiceAccount

kubectl create serviceaccount build-sa

This creates a ServiceAccount object. By itself, it has no permissions. To make it useful, you must:

1. Create a Role (or ClusterRole) defining allowed verbs and resources
2. Create a RoleBinding (or ClusterRoleBinding) attaching that Role to the ServiceAccount

RBAC for ServiceAccounts

The video demonstrates the full workflow:

# 1. Create the ServiceAccount
kubectl create serviceaccount build-sa
 
# 2. Create a Role with specific permissions
kubectl create role build-role \
  --verb=get,list,watch \
  --resource=pods
 
# 3. Bind the Role to the ServiceAccount
kubectl create rolebinding rb \
  --role=build-role \
  --serviceaccount=default:build-sa

Important: When binding a ServiceAccount, the subject block must include the ServiceAccount’s Namespace:

subjects:
- kind: ServiceAccount
  name: build-sa
  namespace: default

Testing Permissions with Impersonation

You can verify a ServiceAccount’s permissions without running inside a Pod:

kubectl auth can-i get pods --as system:serviceaccount:default:build-sa
kubectl get pods --as system:serviceaccount:default:build-sa

The --as flag impersonates the ServiceAccount. If the RoleBinding is correct, the command succeeds; otherwise, it returns Forbidden.

ServiceAccount Tokens

When a ServiceAccount is created, Kubernetes can generate a token Secret of type kubernetes.io/service-account-token. This token is a JWT (JSON Web Token) signed by the cluster’s ServiceAccount key pair (sa.pub / sa.key).

The token Secret contains:

• token — The bearer token for API authentication
• ca.crt — The cluster CA certificate for TLS verification
• namespace — The ServiceAccount’s namespace

Token Mounting in Pods

Every Pod using a ServiceAccount automatically mounts the token as a projected volume at:

/var/run/secrets/kubernetes.io/serviceaccount/

Inside this directory, three files appear:

• token — The JWT bearer token
• ca.crt — CA certificate to verify the API server
• namespace — The Pod’s namespace name

Applications read these files to construct authenticated REST API calls:

curl -k https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/default/pods \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

ImagePullSecrets

ServiceAccounts can also hold imagePullSecrets — references to Secrets of type kubernetes.io/dockerconfigjson that store private registry credentials. When a ServiceAccount has imagePullSecrets, any Pod using that ServiceAccount automatically inherits them, allowing kubelet to pull images from private registries without duplicating the Secret reference in every Pod spec.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-sa
imagePullSecrets:
- name: regcred

CKA Exam Relevance

• ServiceAccount + Role + RoleBinding is a common exam task: grant a specific Pod or automation tool limited API access
• Remember the --as impersonation syntax for testing
• Remember that default ServiceAccount has minimal permissions
• Know the token mount path and the three mounted files
• Know that ServiceAccount subjects in RoleBindings require namespace explicitly

See Also

Wiki Concepts

• Kubernetes Service Account — Deep-dive into ServiceAccount anatomy, token lifecycle, and security best practices
• Kubernetes RBAC — Roles, RoleBindings, and the full permission model
• Kubernetes Authentication & Authorization — API server security pipeline
• Kubernetes Kubeconfig — Client credentials and context switching
• Kubernetes ConfigMaps and Secrets — Secret types including service-account-token and imagePullSecrets
• Pod Fundamentals — Pod spec and serviceAccountName field
• Kubernetes Namespaces — Namespace-scoped identities and default ServiceAccounts

Related Sources

• CKA Day 22 — Authentication & Authorization — The two-gate security model
• CKA Day 23 — RBAC Explained — Namespace-scoped Roles and RoleBindings
• CKA Day 24 — ClusterRole & ClusterRoleBinding — Cluster-scoped RBAC

Creator / Entity

• Tech Tutorials with Piyush — CKA 40-day course creator

---

Ingested: 2026-07-06