Programs inside a cluster often need to talk to the cluster itself.

Most applications running in Kubernetes never need to speak to the cluster’s control system. A web server just answers requests, and a database just stores data. But some programs must. A monitoring tool needs to discover which pods exist so it can collect their metrics. An ingress controller needs to watch for new routes. A deployment tool needs to create and update resources. A program that manages certificates needs to write secrets. All of these programs talk to the Kubernetes API, the cluster’s central control interface.

The API does not simply let anyone in. Every request must answer two questions: who is asking, and are they allowed to do this? The first question is called authentication, and the second is authorisation. For a human administrator, authentication might use a company login. But a program inside a pod is not a human, and it needs a different way to prove who it is. That way is the service account.

What can go wrong without a clear identity

If every program in a cluster shared one identity with wide permissions, then a single compromised application could read secrets, delete workloads, or take over the whole cluster. A careful identity system gives each workload its own badge and only the permissions it truly needs, so that a break-in to one application stays small.

Kubernetes treats people and programs differently.

Kubernetes distinguishes between two kinds of identities that can call its API. The first is a normal user, meaning a human such as an engineer or an administrator. Kubernetes has no object called a user. It does not store users at all. Instead, it trusts an outside system, such as a company login service or a certificate authority, to say who a person is.

The second kind is the service account, which represents a program. Unlike users, service accounts are real Kubernetes objects. They are created, listed, and deleted through the API, and they belong to a namespace. Because they are managed inside the cluster, they can be created automatically and in large numbers, one for each application, without involving any outside system.

A small, namespaced object that names an identity for workloads.

A ServiceAccount is one of the simplest objects in Kubernetes. On its own, it is little more than a name inside a namespace, together with a few optional settings. Its power comes from the connections around it: pods can be told to run as a service account, the cluster issues tokens on its behalf, and permission rules can be attached to it.

Every namespace automatically contains a service account named default. When you create a pod without specifying which service account to use, the pod runs as the default one in its namespace. This is convenient, but it is also a hidden source of risk, because many pods end up sharing one identity that nobody chose deliberately.

flowchart TD
    NS[Namespace] --> SA1[ServiceAccount: default
created automatically]
    NS --> SA2[ServiceAccount: web-app]
    NS --> SA3[ServiceAccount: metrics-reader]
    SA2 --> P1[Pod running the web app]
    SA3 --> P2[Pod running the metrics tool]
    SA1 --> P3[Pods with no service account chosen]
        

Every request carries a name and a set of groups.

When a program uses a service account token to call the API, the API server turns the token into a username and a list of groups. The username follows a fixed pattern that includes the words “system”, “serviceaccount”, the namespace, and the service account name, joined together. This full name is what appears in permission rules and in audit records, so it is worth understanding.

Why groups deserve caution

Permission rules that mention a group apply to every member. A rule that grants a broad permission to the group of all service accounts silently gives that permission to every workload in the cluster, including ones created in the future. Such rules are convenient and dangerous, and reviewers should treat them with suspicion.

A token is a signed statement from the cluster saying “this program is that service account.”

A service account token is a compact, signed piece of text that the cluster issues. It states which service account it belongs to, which namespace it is in, which audience it is meant for, and when it expires. The cluster signs it with a private key, so that anyone with the matching public key, notably the API server, can check that it is genuine and unaltered.

When a pod starts, the kubelet asks the API server for a token for the pod’s service account, and places it as a file inside the container. The program reads the file and sends the token with every API request. The API server checks the signature, the expiry, and the audience, and then knows exactly who is calling.

sequenceDiagram
    participant K as Kubelet
    participant API as API Server
    participant P as Pod and application
    K->>API: Request a token for this pod's service account
    API-->>K: Signed token with expiry
    K->>P: Place token as a file in the container
    P->>API: Request with the token attached
    API->>API: Check signature, expiry, audience, and pod
    API-->>P: Identity accepted, authorisation checked next
        

Modern tokens are short-lived and bound to the pod; older tokens lived forever.

In early versions of Kubernetes, each service account automatically received a long-lived token stored in a Secret. That token never expired, was not tied to any pod, and could be copied and used from anywhere for as long as the service account existed. If a token leaked, the leak had no end date. This design was convenient but weak.

Modern clusters use projected tokens instead. A projected token is requested for a specific pod, has a limited lifetime, and is valid for a specific audience. It becomes invalid when the pod is deleted. The kubelet renews it automatically before it expires. In current versions, the cluster no longer creates the old long-lived secret tokens automatically. They can still be created by hand, but that is discouraged.

flowchart LR
    subgraph Legacy tokens
        L1[Token stored in a Secret] --> L2[No expiry]
        L2 --> L3[Works from anywhere]
        L3 --> L4[Leak lasts until the service account is deleted]
    end
    subgraph Projected tokens
        P1[Token delivered to the pod file system] --> P2[Expires and is renewed]
        P2 --> P3[Bound to the pod and an audience]
        P3 --> P4[Leak is limited in time and scope]
    end
        

A few claims in the token decide whether the API server accepts it.

A service account token is a signed structure with several statements, called claims. The API server reads these claims and checks each one before it trusts the caller. Knowing what they are makes it clear why a token stops working in certain situations.

flowchart TD
    T[Token arrives at the API server] --> S{Signature valid?}
    S -->|No| X[Rejected]
    S -->|Yes| E{Expired?}
    E -->|Yes| X
    E -->|No| A{Audience accepted?}
    A -->|No| X
    A -->|Yes| B{Bound pod and service account still exist?}
    B -->|No| X
    B -->|Yes| OK[Identity established, authorisation next]
        

A standard location and a standard convention make it work with little effort.

Inside every container that mounts it, the token appears in a fixed directory. Next to the token file are two other files: the certificate authority the program should trust when talking to the API server, and a file containing the pod’s namespace. Together, they give a program everything it needs to talk to the API securely.

In-cluster configuration

The standard Kubernetes client libraries have a built-in mode, often called in-cluster configuration, which looks in this standard location, finds the token and certificate, and discovers the API server’s address from environment variables that Kubernetes sets in every container. A program using such a library needs no configuration at all to talk to its own cluster.

sequenceDiagram
    participant A as Application
    participant F as Token file
    participant K as Kubelet
    participant API as API Server
    A->>F: Read token
    A->>API: Request with token
    API-->>A: Success
    Note over K,F: Token nears expiry, kubelet writes a fresh token
    K->>F: Replace token
    A->>F: Re-read token before next requests
    A->>API: Request with the fresh token
    API-->>A: Success
        

A service account can do nothing until someone gives it permissions.

Role-based access control, usually shortened to RBAC, is the system that decides what an identity may do. It is built from four kinds of objects. A role lists permissions within one namespace, such as reading pods. A cluster role lists permissions that can apply cluster-wide, or can be reused in many namespaces. A role binding connects a role to one or more identities inside a namespace. A cluster role binding connects a cluster role to identities across the whole cluster.

flowchart LR
    SA[ServiceAccount
metrics-reader in namespace shop] --> RB[RoleBinding in namespace shop]
    R[Role: can read pods in namespace shop] --> RB
    RB --> G[Permission granted:
read pods in shop only]
        

A shared identity that nobody chose is a quiet source of trouble.

Every namespace has a service account called default, and every pod that does not name another one runs as it. In a fresh cluster, the default service account has no meaningful permissions, so the arrangement looks harmless. The danger appears over time. Someone needs a quick fix, grants a permission to the default service account, and from that moment every pod in the namespace that relies on it silently inherits that permission, including pods created later by other teams for unrelated purposes.

flowchart TD
    A[Someone grants a permission to the default service account] --> B[All pods using the default inherit it]
    B --> C[New unrelated pods appear in the namespace]
    C --> D[They inherit the permission too]
    D --> E[A compromised pod can now use that permission]
        

The workflow is simple: create the identity, grant permissions, and tell the pod to use it.

If an application never talks to the API, it should not carry a key to it.

By default, Kubernetes mounts a token into every pod, whether or not the application ever uses it. For the large majority of applications, which serve web pages or process data and never call the Kubernetes API, this token is unnecessary. But it is still there, sitting in the file system. If an attacker takes control of the application, for example through a vulnerability, the token is an extra weapon lying within reach.

The setting that controls this is called automounting. It can be switched off on the service account, so that no pod using it receives a token, or on the individual pod, which overrides the service account setting. Applications that truly need the API can turn it back on for themselves.

flowchart TD
    A[Pod is created] --> B{Pod setting for automount present?}
    B -->|Yes| C[Follow the pod setting]
    B -->|No| D{Service account setting present?}
    D -->|Yes| E[Follow the service account setting]
    D -->|No| F[Default behaviour: mount a token]
        

A service account can also carry credentials for downloading container images.

Container images often live in private registries that require a login. Kubernetes stores such registry credentials in a special kind of secret, called an image pull secret. Normally, each pod lists the secrets it needs. That is easy to forget, and repeating it in every workload is tedious.

A service account can list image pull secrets, and every pod that runs as that service account automatically receives them. This is a convenient way to give a whole application, or a whole namespace if you use the default service account, access to a private registry without changing each workload definition.

sequenceDiagram
    participant U as User
    participant SA as ServiceAccount with pull secret listed
    participant API as API Server
    participant K as Kubelet
    participant R as Private registry
    U->>API: Create pod using the service account
    API->>API: Add the service account's pull secrets to the pod
    K->>R: Pull image using the credentials
    R-->>K: Image delivered
    K->>K: Start the container
        

A pod’s identity can be recognised beyond the cluster, without long-lived passwords.

Service account tokens are not only useful for the Kubernetes API. Because they are signed, time-limited, and carry an audience, they can prove a pod’s identity to other systems. A pod can request a projected token intended for a specific audience, such as a secrets manager or a cloud provider. The external system checks the signature against the cluster’s published public keys, and then trusts the identity in the token.

sequenceDiagram
    participant P as Pod
    participant K as Kubelet
    participant X as External system such as a cloud or secrets manager
    participant D as Cluster issuer keys, published for verification
    K->>P: Mount token with audience for the external system
    P->>X: Present token and ask for access
    X->>D: Fetch public keys and verify signature
    D-->>X: Keys
    X->>X: Check issuer, subject, audience, expiry
    X-->>P: Short-lived credentials for the external service
        

Automation systems often need cluster access, and they need to get it safely.

Build pipelines and deployment tools frequently live outside the cluster, and yet they need to call its API. It is tempting to create a service account, generate a token that never expires, and paste it into the pipeline’s secret store. This works, and it is one of the most common ways clusters get compromised, because that token is a permanent key that can be copied and used from anywhere.

flowchart TD
    A[Pipeline needs to deploy] --> B{Can it use federated identity?}
    B -->|Yes| C[Use it: no stored secret]
    B -->|No| D{Can it request a short-lived token?}
    D -->|Yes| E[Request a token with a short lifetime for each run]
    D -->|No| F{Can deployment be pulled from inside the cluster?}
    F -->|Yes| G[Use an in-cluster delivery agent]
    F -->|No| H[Last resort: long-lived token, tightly scoped and rotated]
        

Who actually needs a service account with permissions?

Some permissions look modest but effectively hand over much more.

Not all permissions are equal. Some seem small, yet they allow a holder to obtain far greater powers. Understanding these escalation paths is central to service account security, because an attacker who takes over one pod usually starts with the modest permissions of its service account and then looks for a way up.

flowchart TD
    A[Attacker compromises a low-privilege pod] --> B[Reads its service account token]
    B --> C{Can the account create pods in the namespace?}
    C -->|Yes| D[Starts a new pod using a more powerful service account]
    D --> E[Gains that account's permissions]
    C -->|No| F{Can it read secrets or create tokens?}
    F -->|Yes| G[Obtains credentials of other identities]
    G --> E
    F -->|No| H[Damage stays limited]
        

A set of habits that keep the identity system small, clear, and safe.

If you cannot see what an identity does, you cannot tell when it goes wrong.

Every request to the API can be recorded in the audit log, together with the identity that made it. For service accounts, the recorded username is the full name that includes the namespace and the account name. This is why one service account per workload matters so much: when the log shows an unexpected action, the name points to the exact application, and you can investigate the right place immediately.

flowchart TD
    A[API request with service account token] --> L[Audit log entry:
identity, action, resource, result]
    L --> S[Log collection and search]
    S --> R1[Alert: many denied requests]
    S --> R2[Alert: secrets read by unexpected account]
    S --> R3[Alert: new cluster-wide binding created]
    S --> R4[Alert: token minted for a privileged account]
    R1 --> I[Investigate the workload behind the name]
    R2 --> I
    R3 --> I
    R4 --> I
        

Most problems are either a missing permission, a missing token, or an expired one.

When an application cannot talk to the API, the error message usually tells you which of the three groups of problem you face. A forbidden error means the identity was recognised but not permitted. An unauthorised error means the identity was not recognised at all, often because of a missing, expired, or invalid token. A refused pod creation points to a missing service account. Reading the exact message carefully saves a lot of guessing.

Identity is cheap, but token handling and permission checks add up in large clusters.

Service accounts themselves are tiny objects, and having thousands of them is not a problem. The costs come from the activity around them. Every pod that mounts a token causes the kubelet to request one and to renew it periodically. Every API request triggers a permission check. Clusters with many pods, and applications that call the API very frequently, generate a lot of both.

Reliable arrangements used in well-run clusters.

flowchart TD
    A[New application] --> B[Create dedicated service account]
    B --> C{Needs Kubernetes API?}
    C -->|No| D[Disable token mounting, no permissions]
    C -->|Yes| E[Write minimal namespaced role]
    E --> F[Bind role to the service account]
    F --> G{Needs cloud or external access?}
    G -->|Yes| H[Map to workload identity with narrow scope]
    G -->|No| I[Done]
    D --> I
    H --> I
        

Habits that create quiet, serious risk.

A short checklist for safe use of service accounts.

How teams handle service accounts in daily operations.

A namespaced object that represents the identity of a program running in a pod, or of an automated tool. The cluster issues tokens for it, and permission rules decide what it may do.

Users represent humans and are managed outside the cluster. Service accounts represent programs, are real Kubernetes objects, and belong to a namespace.

Each namespace has one, and pods that name no other account run as it. It has no meaningful permissions by default, and permissions should not be added to it.

The kubelet requests a token from the API server for the pod’s service account and mounts it as a file in the container. The kubelet renews it before it expires.

Projected tokens, used by default in current versions, are time-limited and bound to the pod. Old-style secret tokens did not expire, and should be removed where possible.

Create a role that lists the allowed actions, and a binding that attaches the role to the service account. Use namespaced roles and bindings wherever possible.

No. Applications that never call the Kubernetes API should have automatic mounting disabled, which removes an unnecessary credential from the pod.

No. A pod can only use a service account from its own namespace, although permission bindings can refer to service accounts in other namespaces.

No. It is fixed at creation. Change the workload template so that new pods, which replace the old ones, use the new account.

Prefer federated identity or short-lived tokens requested on demand, or an in-cluster delivery agent. Avoid storing never-expiring tokens.

It probably reads the token file once and never again. Tokens are renewed, so clients must re-read the file. Use a current client library.

Through workload identity: the cluster’s token, signed and audience-bound, is exchanged with the cloud provider for short-lived cloud credentials, according to a mapping you configure.

A service account is the identity of a program inside a Kubernetes cluster. It is a small namespaced object that the cluster uses to issue signed tokens, which pods present to the API server to prove who they are. What the identity is then allowed to do is decided separately, through roles and bindings. Modern clusters issue short-lived, pod-bound, audience-specific tokens that the kubelet renews automatically, replacing the never-expiring secret tokens of the past.

Because service accounts sit where convenience meets risk, the most important habits are simple: give each workload its own identity, start with no permissions, add only what is needed in the smallest scope, switch off tokens that are not used, prefer short-lived credentials over stored ones, and watch what identities actually do. Remember the escalation paths, especially that the right to create pods in a namespace is the right to use every identity in it. With these habits, service accounts give your workloads a safe, clear, and auditable identity.