Service accounts in Kubernetes - Deep Dive

Overview - Service accounts

What is it?

Service accounts in Kubernetes are special accounts used by applications running inside pods to interact securely with the Kubernetes API. They provide an identity for processes that run in pods, allowing controlled access to cluster resources. Unlike user accounts, service accounts are managed by Kubernetes and tied to namespaces. They help pods authenticate and authorize actions without embedding sensitive credentials in the application code.

Why it matters

Without service accounts, applications inside Kubernetes would have no secure way to prove who they are when talking to the cluster. This would force developers to embed static credentials inside containers, risking leaks and security breaches. Service accounts solve this by providing automatic, short-lived credentials managed by Kubernetes, improving security and simplifying access control. This makes clusters safer and easier to manage at scale.

Where it fits

Before learning service accounts, you should understand Kubernetes basics like pods, namespaces, and RBAC (Role-Based Access Control). After mastering service accounts, you can explore advanced security topics like Pod Security Policies, Network Policies, and external identity providers for Kubernetes.

Mental Model

Core Idea

A service account is a Kubernetes-managed identity that pods use to securely access the cluster API without hardcoding credentials.

Think of it like...

Imagine a hotel where guests (pods) need a key card (service account token) to enter certain rooms (cluster resources). The hotel issues these cards automatically and can revoke or renew them anytime, so guests don’t carry permanent keys.

┌───────────────┐       ┌─────────────────────┐
│   Pod (App)   │──────▶│ Service Account Token│
└───────────────┘       └─────────────────────┘
          │                        │
          │ Uses token to access   │
          ▼                        ▼
   ┌───────────────────────────────┐
   │ Kubernetes API Server          │
   │ Checks token, applies RBAC    │
   └───────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What is a Service Account in Kubernetes

Concept: Introduce the basic concept of service accounts as identities for pods.

In Kubernetes, a service account is an automatically created identity for processes running inside pods. Each namespace has a default service account, and pods use these accounts to authenticate to the Kubernetes API. This avoids embedding static credentials inside containers.

Result

Pods have a unique identity to interact with the cluster securely.

Understanding that pods need identities to communicate with the cluster is the foundation for grasping Kubernetes security.

2

Foundation

How Service Account Tokens Work

Concept: Explain the token mechanism that service accounts use for authentication.

Kubernetes creates a secret containing a JSON Web Token (JWT) for each service account. This token is mounted automatically inside pods at a known path. When the pod talks to the API server, it presents this token to prove its identity.

Result

Pods can authenticate to the API server using the mounted token without manual intervention.

Knowing that tokens are automatically managed and rotated helps avoid insecure manual credential handling.

3

Intermediate

Default vs Custom Service Accounts

🤔Before reading on: do you think every pod uses the same service account by default or a unique one? Commit to your answer.

Concept: Distinguish between the default service account and creating custom ones for specific permissions.

By default, pods use the 'default' service account in their namespace. However, you can create custom service accounts with specific permissions and assign them to pods. This allows fine-grained access control tailored to application needs.

Result

Pods can have different identities with different access rights.

Understanding custom service accounts enables secure, least-privilege access patterns in production.

4

Intermediate

Binding Roles to Service Accounts

🤔Before reading on: do you think service accounts have permissions by default or need explicit role bindings? Commit to your answer.

Concept: Introduce RoleBindings and ClusterRoleBindings to grant permissions to service accounts.

Service accounts themselves have no permissions until you bind them to roles using RoleBinding (namespace-scoped) or ClusterRoleBinding (cluster-wide). These bindings define what actions the service account can perform on which resources.

Result

Service accounts gain controlled access to Kubernetes resources based on assigned roles.

Knowing that permissions are separate from identities clarifies how Kubernetes enforces security.

5

Advanced

Token Projection and Bound Service Account Tokens

🤔Before reading on: do you think service account tokens are always long-lived or can be short-lived? Commit to your answer.

Concept: Explain the newer feature of projected service account tokens with expiration and audience restrictions.

Kubernetes supports projected service account tokens that are short-lived and can be scoped to specific audiences. These tokens improve security by limiting token lifetime and usage, reducing risk if a token leaks.

Result

Pods use safer, time-limited tokens for API access.

Understanding token projection helps implement modern security best practices in Kubernetes.

6

Expert

Service Account Token Volume Mount Internals

🤔Before reading on: do you think the token file inside pods is static or dynamically updated? Commit to your answer.

Concept: Dive into how Kubernetes manages the token file inside pods, including automatic refresh and expiration handling.

The token file mounted inside pods is managed by the kubelet and API server. It is dynamically updated before expiration without restarting the pod. This seamless refresh ensures continuous authentication without manual intervention.

Result

Pods maintain valid tokens automatically, avoiding downtime or manual token refresh.

Knowing the dynamic nature of token mounting prevents confusion about token expiration issues in production.

Under the Hood

Kubernetes creates a service account object in the API server and automatically generates a secret containing a JWT token linked to that account. When a pod is created with a service account, the kubelet mounts the token secret as a volume inside the pod. The pod uses this token to authenticate API requests. The API server validates the token signature and checks the associated service account's permissions via RBAC before allowing actions.

Why designed this way?

This design centralizes identity and access management in Kubernetes, avoiding manual credential distribution. Using JWT tokens allows stateless, verifiable authentication. Automating token mounting and refresh reduces operational overhead and security risks from stale or leaked credentials. Alternatives like static tokens or embedding credentials in images were rejected due to security and scalability concerns.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Service       │       │ Secret with   │       │ Pod Volume    │
│ Account Obj   │──────▶│ JWT Token     │──────▶│ Mounts Token  │
└───────────────┘       └───────────────┘       └───────────────┘
          │                                               │
          ▼                                               ▼
┌───────────────────────┐                      ┌───────────────────────┐
│ Kubernetes API Server  │◀─────────────────────│ Pod uses Token to     │
│ Validates Token & RBAC│                      │ Authenticate Requests │
└───────────────────────┘                      └───────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think the default service account has full cluster admin rights? Commit yes or no.

Common Belief: The default service account has full permissions to do anything in the cluster.

Reality: The default service account has no permissions by default; it cannot perform any actions unless explicitly granted.

Why it matters: Assuming default accounts have full rights can lead to overestimating security and missing necessary role bindings, causing application failures.

Quick: Do you think service account tokens are permanent and never expire? Commit yes or no.

Common Belief: Service account tokens are permanent and do not expire once issued.

Reality: Traditional service account tokens are long-lived but can be revoked; newer projected tokens are short-lived and automatically refreshed.

Why it matters: Believing tokens never expire can cause security risks if tokens are leaked and not rotated.

Quick: Do you think service accounts are the same as user accounts? Commit yes or no.

Common Belief: Service accounts and user accounts are the same and interchangeable.

Reality: Service accounts are for pods and processes inside the cluster, while user accounts represent human users outside the cluster.

Why it matters: Confusing these leads to misconfigured access controls and security policies.

Quick: Do you think mounting service account tokens inside pods is optional? Commit yes or no.

Common Belief: Mounting service account tokens inside pods is optional and often skipped.

Reality: By default, tokens are automatically mounted; skipping requires explicit configuration and can break API access.

Why it matters: Not mounting tokens unintentionally disables pod authentication, causing failures in cluster communication.

Expert Zone

1

Service account tokens are JWTs signed by the cluster’s private key, allowing stateless verification without contacting an external service.

2

The kubelet refreshes projected tokens inside pods before expiration, but this requires the pod to have the projected token volume configured explicitly.

3

Using custom service accounts with minimal permissions is critical for the principle of least privilege, but many clusters still rely on the default account, increasing risk.

When NOT to use

Service accounts are not suitable for authenticating external users or services outside the cluster; use external identity providers or OIDC instead. For workloads requiring complex identity federation, consider integrating Kubernetes with external IAM systems.

Production Patterns

In production, teams create dedicated service accounts per application or microservice with scoped permissions. They use RoleBindings to enforce least privilege and enable auditing. Token projection with expiration is enabled for enhanced security. Automation tools manage service account lifecycle and bindings to reduce human error.

Connections

OAuth 2.0 Access Tokens

Service account tokens are similar to OAuth access tokens as short-lived credentials used to prove identity and authorize access.

Understanding OAuth token flows helps grasp how Kubernetes tokens authenticate pods securely without passwords.

Unix User Accounts and Permissions

Service accounts in Kubernetes are like Unix user accounts that define identity and permissions for processes.

Knowing Unix user and group permissions clarifies how Kubernetes separates identity from access control.

Hotel Key Card Systems

Both systems issue temporary keys (tokens) to guests (pods/users) that allow controlled access to resources (rooms/APIs).

Recognizing this pattern across domains highlights the importance of temporary, revocable credentials for security.

Common Pitfalls

#1 Assuming all pods automatically have permissions to access the Kubernetes API.

Wrong approach:

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: app
image: myapp
serviceAccountName: default

# No RoleBinding created

Correct approach:

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: app
image: myapp
serviceAccountName: my-custom-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: ServiceAccount
name: my-custom-sa
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io

Root cause:

Misunderstanding that service accounts have no permissions unless explicitly granted via RBAC.

#2 Hardcoding service account tokens inside container images or environment variables.

Wrong approach:

ENV SERVICE_ACCOUNT_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Correct approach:

Let Kubernetes mount the token automatically as a volume inside the pod at /var/run/secrets/kubernetes.io/serviceaccount/token

Root cause:

Lack of awareness that Kubernetes manages tokens and mounts them securely, avoiding manual embedding.

#3 Disabling automatic token mounting without providing an alternative authentication method.

Wrong approach:

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
automountServiceAccountToken: false
containers:
- name: app
image: myapp

Correct approach:

Either keep automountServiceAccountToken: true or provide another secure way for the pod to authenticate to the API server.

Root cause:

Not understanding that disabling token mounting disables pod authentication unless replaced.

Key Takeaways

Service accounts provide pods with managed identities to securely access the Kubernetes API without embedding static credentials.

Tokens for service accounts are automatically created, mounted, and refreshed by Kubernetes, improving security and ease of use.

Permissions for service accounts are controlled separately via RoleBindings and ClusterRoleBindings, enabling fine-grained access control.

Using custom service accounts with minimal permissions follows the principle of least privilege and reduces security risks.

Understanding the lifecycle and management of service account tokens helps prevent common security pitfalls in Kubernetes clusters.

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