Service accounts in Kubernetes - Step-by-Step Execution

Process Flow - Service accounts

Create ServiceAccount YAML

↓

kubectl apply -f serviceaccount.yaml

↓

Kubernetes API Server creates ServiceAccount object

↓

Pod spec references ServiceAccount

↓

Pod starts with ServiceAccount token mounted

↓

Pod uses token to authenticate to API Server

This flow shows how a Kubernetes ServiceAccount is created, applied, linked to a Pod, and used for API authentication.

Execution Sample

Kubernetes

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: app
    image: busybox
    command: ["sleep", "3600"]

This YAML creates a ServiceAccount and a Pod that uses it to authenticate with the Kubernetes API.

Process Table

Step	Action	Resource Created/Updated	State Change	Result
1	Apply ServiceAccount YAML	ServiceAccount 'my-service-account'	ServiceAccount object created in cluster	ServiceAccount available for pods
2	Apply Pod YAML referencing ServiceAccount	Pod 'my-pod'	Pod spec includes serviceAccountName: my-service-account	Pod created (Pending)
3	Pod starts running	Pod 'my-pod' running	ServiceAccount token mounted in Pod filesystem	Pod can authenticate to API Server using token
4	Pod uses token to call API	API Server authentication	Token validated	Pod authorized as 'my-service-account'
5	Pod terminates or deleted	Pod removed	ServiceAccount remains	ServiceAccount reusable for other pods

💡 Pod lifecycle ends; ServiceAccount persists independently

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
ServiceAccount 'my-service-account'	Not present	Created	Exists	Exists	Exists	Exists
Pod 'my-pod'	Not present	Not present	Created (Pending)	Running with SA token	Running with SA token	Deleted
SA Token in Pod	None	None	None	Mounted	Used for API auth	Removed with Pod

Key Moments - 3 Insights

Why does the ServiceAccount still exist after the Pod is deleted?

Because ServiceAccounts are cluster resources independent of Pods. The execution_table row 5 shows the Pod is removed but the ServiceAccount remains for reuse.

How does the Pod get the ServiceAccount token?

The Pod spec references the ServiceAccount name (row 2), so Kubernetes mounts the token automatically inside the Pod when it starts (row 3).

Can a Pod authenticate to the API Server without a ServiceAccount?

By default, Pods use the default ServiceAccount in their namespace. Without specifying one, Kubernetes still mounts a token for authentication.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the ServiceAccount token mounted inside the Pod?

A Step 3

B Step 4

C Step 2

D Step 5

💡 Hint

Check the 'State Change' column for when the token is mounted (Step 3).

According to variable_tracker, what is the state of the Pod after Step 4?

A Not present

B Created but not running

C Running with SA token

D Deleted

💡 Hint

Look at the 'Pod my-pod' row under 'After Step 4' column.

If the Pod YAML did not specify serviceAccountName, what would happen?

A Pod would not start

B Pod would use the default ServiceAccount

C Pod would have no API access

D Pod would create a new ServiceAccount automatically

💡 Hint

Recall Kubernetes default behavior for Pods without explicit ServiceAccount (key_moments #3).

Concept Snapshot

ServiceAccount in Kubernetes:
- Defines identity for Pods to access API Server
- Created as a cluster resource (kubectl apply)
- Pod spec references ServiceAccount by name
- Kubernetes mounts token inside Pod automatically
- Token used for API authentication
- ServiceAccount persists beyond Pod lifecycle

Full Transcript

This visual execution trace shows how Kubernetes ServiceAccounts work. First, a ServiceAccount resource is created using YAML and applied to the cluster. Then, a Pod is created referencing this ServiceAccount by name. When the Pod starts, Kubernetes mounts the ServiceAccount token inside the Pod automatically. The Pod uses this token to authenticate to the Kubernetes API Server. Even after the Pod is deleted, the ServiceAccount remains available for other Pods. This separation allows secure and reusable identities for Pods to interact with the cluster.

Practice

1. What is the main purpose of a ServiceAccount in Kubernetes?

easy

A. To schedule pods on specific nodes

B. To give a pod an identity and control its permissions inside the cluster

C. To manage network policies between pods

D. To store container images for pods

Solution

1. Step 1: Understand what identity means in Kubernetes

   A ServiceAccount provides an identity for pods so they can authenticate to the Kubernetes API.

2. Step 2: Recognize the role of permissions

   ServiceAccounts are linked to permissions (via Roles or ClusterRoles) to control what pods can do.

3. Final Answer:

   To give a pod an identity and control its permissions inside the cluster -> Option B

4. Quick Check:

   ServiceAccount = Pod identity and permissions [OK]

Hint: ServiceAccount = pod identity + permissions [OK]

Common Mistakes:

• Confusing ServiceAccount with image storage
• Thinking ServiceAccount manages pod scheduling
• Mixing ServiceAccount with network policies

2. Which of the following is the correct YAML snippet to create a ServiceAccount named my-service-account?

easy

A. apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service-account

B. apiVersion: v1
kind: Pod
metadata:
name: my-service-account

C. apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account

D. apiVersion: v1
kind: Namespace
metadata:
name: my-service-account

Solution

1. Step 1: Identify the correct kind for ServiceAccount

   The kind must be ServiceAccount to create a service account resource.

2. Step 2: Check the apiVersion and metadata

   ServiceAccount uses apiVersion: v1 and metadata with the name field.

3. Final Answer:

   apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account -> Option C

4. Quick Check:

   ServiceAccount YAML uses kind: ServiceAccount [OK]

Hint: ServiceAccount YAML always uses kind: ServiceAccount [OK]

Common Mistakes:

• Using wrong kind like Pod or Deployment
• Wrong apiVersion for ServiceAccount
• Confusing Namespace with ServiceAccount

3. Given this command: kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}', what does it output?

medium

A. The name of the first secret linked to the default ServiceAccount

B. The list of all pods using the default ServiceAccount

C. The token value inside the secret

D. An error because jsonpath is invalid

Solution

1. Step 1: Understand the command structure

   The command fetches the ServiceAccount named 'default' and extracts the first secret's name using jsonpath.

2. Step 2: Interpret the jsonpath expression

   The expression {.secrets[0].name} selects the name of the first secret linked to the ServiceAccount.

3. Final Answer:

   The name of the first secret linked to the default ServiceAccount -> Option A

4. Quick Check:

   jsonpath extracts secret name from ServiceAccount [OK]

Hint: jsonpath {.secrets[0].name} gets first secret name [OK]

Common Mistakes:

• Thinking it lists pods instead of secrets
• Expecting secret token value instead of secret name
• Assuming jsonpath syntax is wrong

4. You created a ServiceAccount but your pod fails to use it. Which of these is the most likely cause?

medium

A. The ServiceAccount was created in a different namespace

B. The pod image is missing

C. The ServiceAccount has no secrets linked

D. The pod spec does not specify the ServiceAccount name

Solution

1. Step 1: Check namespace consistency

   ServiceAccounts are namespace-scoped. If the pod is in one namespace but the ServiceAccount in another, the pod cannot use it.

2. Step 2: Verify pod spec and ServiceAccount existence

   Even if the ServiceAccount exists in the same namespace, the pod must specify the ServiceAccount name in its spec to use it.

3. Final Answer:

   The pod spec does not specify the ServiceAccount name -> Option D

4. Quick Check:

   Pod spec must specify serviceAccountName to use it [OK]

Hint: Pod spec must specify serviceAccountName [OK]

Common Mistakes:

• Forgetting to specify serviceAccountName in pod spec
• Assuming missing secrets cause pod failure
• Blaming pod image unrelated to ServiceAccount

5. You want a pod to use a custom ServiceAccount named app-sa and access the Kubernetes API with limited permissions. Which steps should you follow?

hard

A. Create the ServiceAccount app-sa, create a Role with permissions, bind the Role to app-sa, then specify serviceAccountName: app-sa in the pod spec

B. Create a RoleBinding for the default ServiceAccount, then deploy the pod without specifying serviceAccountName

C. Create a ClusterRole with full permissions and assign it to the pod directly

D. Deploy the pod first, then create the ServiceAccount and Role

Solution

1. Step 1: Create the custom ServiceAccount

   Define and create app-sa in the pod's namespace to give the pod an identity.

2. Step 2: Define permissions and bind them

   Create a Role with limited permissions and bind it to app-sa using a RoleBinding.

3. Step 3: Specify the ServiceAccount in the pod spec

   Set serviceAccountName: app-sa in the pod spec so the pod uses this identity and permissions.

4. Final Answer:

   Create the ServiceAccount app-sa, create a Role with permissions, bind the Role to app-sa, then specify serviceAccountName: app-sa in the pod spec -> Option A

5. Quick Check:

   Custom ServiceAccount + Role + RoleBinding + pod spec = correct setup [OK]

Hint: Create SA, Role, RoleBinding, then assign SA to pod [OK]

Common Mistakes:

• Assigning permissions to default ServiceAccount instead of custom
• Creating ClusterRole with too many permissions
• Deploying pod before creating ServiceAccount and Role