🚀 K8s YSeries #3-Why service accounts are critical in k8s

rjshk013 June 21, 2025

Service accounts in Kubernetes serve several critical purposes for identity, security, and access control. Here’s why they’re essential:

Core Purpose: Pod Identity & Authentication

Service accounts provide identity to pods – they’re how Kubernetes knows “who” a pod is when it tries to access resources. Every pod runs with a service account, whether you specify one or not.

Key Use Cases:

1. Kubernetes API Access When pods need to interact with the Kubernetes API (like reading secrets, updating deployments, or watching for changes), they authenticate using their service account credentials:

# Pod using custom service account
apiVersion: v1
kind: Pod
spec:
  serviceAccountName: api-reader
  containers:
  - name: app
    image: my-app

2. RBAC (Role-Based Access Control) Service accounts are the foundation of Kubernetes permissions. You bind roles to service accounts to control what pods can do:

# Give service account permission to read pods
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: pod-reader
roleRef:
  kind: Role
  name: pod-reader

3. External System Authentication Service accounts can be linked to external identity systems:

• AWS: IRSA (IAM Roles for Service Accounts) for cloud resource access
• GCP: Workload Identity for Google Cloud services
• Azure: Azure AD Workload Identity

4. Secret Management Service accounts can be associated with specific secrets, controlling which pods can access sensitive data like API keys or certificates.

Security Benefits:

Principle of Least Privilege: Different workloads get only the permissions they need

# Database backup pod gets S3 access
# Web frontend gets no cloud permissions
# Monitoring pod gets read-only cluster access

Isolation: Prevents pods from accessing resources they shouldn’t have access to

Auditability: All actions can be traced back to specific service accounts

Default Behavior:

If you don’t specify a service account, pods use the default service account in their namespace, which typically has minimal permissions.

Real-World Example:

# Service account for a monitoring application
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/prometheus-role
---
# Pod using the service account
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: prometheus  # Uses specific identity
      containers:
      - name: prometheus
        image: prometheus:latest

Bottom line: Service accounts are Kubernetes’ way of implementing “identity” for workloads, enabling secure, auditable, and fine-grained access control both within the cluster and to external systems.