DevOps Dictionary

Kubernetes ServiceAccount is a Kubernetes identity used by pods to authenticate to the Kubernetes API server and access cluster resources. In practical terms, it gives a workload its own cluster identity, so the application running in a pod can list ConfigMaps, read Secrets, create Jobs, call custom resources, or interact with other Kubernetes APIs when it has permission to do so.

What a Kubernetes ServiceAccount does

A ServiceAccount answers a basic question inside a cluster: “Who is this pod acting as?”

When a pod talks to the Kubernetes API, the API server needs to authenticate the request and then check whether that identity is allowed to perform the requested action. A ServiceAccount provides that identity for workloads.

Common uses include:

• Letting a controller watch and update Kubernetes resources.
• Allowing a CI/CD runner inside the cluster to create pods or Jobs.
• Giving an application permission to read a specific ConfigMap or Secret.
• Allowing an operator to manage custom resources.
• Connecting Kubernetes workloads to cloud IAM systems, such as AWS IAM Roles for Service Accounts on EKS.

How it works

ServiceAccounts are namespaced Kubernetes objects. A pod can reference a specific ServiceAccount in its pod spec. If you do not specify one, Kubernetes uses the namespace’s default ServiceAccount.

A basic pod configuration looks like this:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  serviceAccountName: app-reader
  containers:
    - name: app
      image: example/app:1.0

When the pod starts, Kubernetes makes credentials available to the pod, usually through a projected token volume. The application can use that token to authenticate to the Kubernetes API server.

Authentication confirms the pod’s identity. Authorization is handled separately, usually through Kubernetes RBAC.

ServiceAccount and RBAC

A ServiceAccount by itself does not grant useful permissions. You normally pair it with Role-Based Access Control, or RBAC.

The main RBAC objects are:

• Role: Grants permissions within one namespace.
• ClusterRole: Grants permissions that can apply across the cluster or to cluster-scoped resources.
• RoleBinding: Assigns a Role or ClusterRole to a user, group, or ServiceAccount within a namespace.
• ClusterRoleBinding: Assigns a ClusterRole across the cluster.

For example, an application that needs to read ConfigMaps in the payments namespace might use a ServiceAccount named payments-config-reader, a Role that allows get and list on ConfigMaps, and a RoleBinding that connects the two.

Common use cases

• Controllers and operators: A custom controller needs permission to watch resources and update their status.
• Deployment automation: A pipeline running inside Kubernetes may need permission to create Deployments, Services, or Jobs. Teams often manage this with infrastructure as code, such as when they deploy Kubernetes resources using Terraform.
• Platform services: Tools such as External Secrets Operator, cert-manager, Argo CD, and Crossplane often rely on ServiceAccounts with carefully scoped permissions.
• Cloud access: On managed Kubernetes platforms, a ServiceAccount can map to a cloud identity so a pod can access resources like object storage, queues, or databases without static cloud keys.
• Batch workloads: Jobs and CronJobs may need temporary access to read data, write results, or update Kubernetes objects.

Real-world example

Suppose you run a reporting service in Kubernetes. The service needs to read a Secret named reporting-db-credentials and list Jobs in its namespace. You can create a dedicated ServiceAccount named reporting-service, grant it only those permissions with a Role, and bind the Role to that ServiceAccount.

This is safer than using the default ServiceAccount or giving the pod broad permissions. If the reporting service is compromised, the attacker gets only the permissions assigned to that workload, not broad access to the cluster.

Default ServiceAccount

Every namespace has a ServiceAccount named default. Pods use it automatically when you do not set serviceAccountName.

For production workloads, it is usually better to create a dedicated ServiceAccount per application or component. This makes permissions easier to audit and limits blast radius. You can also set automountServiceAccountToken: false for pods that do not need to call the Kubernetes API.

apiVersion: v1
kind: Pod
metadata:
  name: no-api-access
spec:
  automountServiceAccountToken: false
  containers:
    - name: app
      image: example/app:1.0

ServiceAccount tokens

A ServiceAccount token is the credential a pod uses to authenticate as its ServiceAccount. Modern Kubernetes clusters use short-lived, automatically rotated projected tokens by default. Older clusters often used long-lived Secret-based tokens, which are harder to secure and should be avoided where possible.

For security-sensitive clusters, check:

• Whether tokens are automatically mounted into pods that do not need them.
• Whether any old long-lived ServiceAccount token Secrets still exist.
• Whether workloads use short-lived tokens with the right audience and expiration.
• Whether RBAC permissions match the workload’s actual needs.

ServiceAccount vs Kubernetes user account

A ServiceAccount is for workloads running in the cluster, such as pods, controllers, and operators.

A Kubernetes user account represents a person or external system that authenticates to the API server, often through client certificates, OIDC, SSO, or a cloud provider’s IAM integration.

• ServiceAccount: Used by pods and in-cluster workloads.
• User account: Used by humans, CI systems, or external clients accessing the cluster API.

ServiceAccount and cloud IAM

In cloud Kubernetes environments, ServiceAccounts are often connected to cloud IAM identities. For example, Amazon EKS supports IAM Roles for Service Accounts, commonly called IRSA. This lets a pod use an AWS IAM role through its Kubernetes ServiceAccount instead of storing AWS access keys in a Secret.

This pattern is common for workloads that need access to AWS services such as S3, SQS, DynamoDB, or Secrets Manager. It also matters when deploying platform tooling on EKS, such as in an Apache Airflow deployment on AWS EKS.

Benefits

• Workload-specific identity: Each application or controller can have its own identity.
• Least privilege access: RBAC can limit each workload to only the API actions it needs.
• Better auditability: Kubernetes audit logs can show which ServiceAccount made an API request.
• Safer cloud access: Cloud IAM integrations reduce the need for static credentials in containers.
• Automation-friendly: ServiceAccounts work well with GitOps, operators, CI/CD, Terraform, and Crossplane workflows.

Tradeoffs and limitations

• Permissions are easy to overgrant: Broad ClusterRoles can give a workload more access than it needs.
• The default ServiceAccount can hide risk: Teams may forget that pods receive an identity unless token mounting is disabled.
• RBAC can become complex: Large clusters need naming conventions, reviews, and cleanup processes.
• Cloud IAM mappings add another layer: You must manage both Kubernetes RBAC and cloud provider permissions.
• Compromised pods can use their token: A pod with API permissions can make API calls until the token expires or access is revoked.

Good practices

• Create a dedicated ServiceAccount for each workload that needs Kubernetes API access.
• Avoid using the default ServiceAccount for production applications.
• Grant the smallest set of verbs and resources needed, such as get on one Secret instead of broad access to all Secrets.
• Use namespace-scoped Roles when cluster-wide access is not required.
• Disable token mounting with automountServiceAccountToken: false for workloads that do not call the Kubernetes API.
• Review ClusterRoleBindings regularly, especially those granting cluster-admin.
• Use cloud-native identity mapping instead of static cloud credentials when running on managed Kubernetes.

Where it fits in Kubernetes automation

ServiceAccounts are often part of platform automation. Tools that create or manage infrastructure from Kubernetes need identities with specific permissions. For example, Crossplane uses Kubernetes resources and controllers to manage cloud infrastructure, and ServiceAccounts are part of how those controllers operate securely. You can see this pattern in workflows that deploy AWS resources using Crossplane on Kubernetes.

ServiceAccounts also matter during cluster maintenance. After upgrades, you should verify workloads that depend on API authentication, token behavior, RBAC, and cloud IAM integrations. This is especially useful when following practical Kubernetes upgrade tips for startups.

Short definition

A Kubernetes ServiceAccount is the identity assigned to a pod so it can authenticate to the Kubernetes API. It becomes useful when combined with RBAC permissions, which define what that workload is allowed to do inside the cluster.