kubernetesrbacPractitioner

Mastering Kubernetes Service Accounts: RBAC in Action

5 min read Kubernetes DocsApr 28, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

Service accounts exist to provide an identity for processes running in a Pod, distinguishing them from user accounts meant for human interaction. This separation is crucial for security and operational efficiency in Kubernetes environments. By leveraging service accounts, you can ensure that your applications have the necessary permissions to interact with the Kubernetes API without exposing user credentials.

ServiceAccount tokens can be bound to various API objects within the kube-apiserver, including Pods, Secrets, and Nodes. When a token is bound to an object, it carries additional claims in the JWT that identify the object it is associated with. For instance, if a token is bound to a Pod, it will include the Pod's metadata in its claims. This mechanism allows for fine-grained access control, ensuring that only the intended processes can interact with specific resources. You can create a token for a service account and bind it to a Pod using commands like kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod".

In production, be aware that while the TokenReview API can be used to verify the claims within a token, the API server does not persist TokenReview objects, which can lead to confusion. Additionally, the presence of both pod and node claims in a token indicates it is bound to a Pod, but the API server does not check for the existence of the referenced Node object. This means that if the Node is deleted, the token remains valid until it expires. Always use the TokenReview API to ensure the claims are still valid before relying on a token for access control. Keep in mind that the behavior of the aud and iss fields in the JWT can vary between clusters, which could impact your authentication logic.

Key takeaways

→Understand the distinction between user accounts and service accounts for better security management.
→Utilize bound service account tokens to enforce access control based on specific Kubernetes API objects.
→Leverage the TokenReview API to verify the validity of a token's claims before granting access.
→Be cautious of the fact that tokens can remain valid even if their bound objects are deleted until they expire.

Why it matters

Managing service accounts effectively can significantly enhance your Kubernetes security model, ensuring that applications have the right permissions without exposing sensitive user credentials.

Code examples

Bash

kubectl create token my-sa --bound-object-kind="Pod"--bound-object-name="test-pod"

YAML

apiVersion:authentication.k8s.io/v1
kind:TokenReview
spec:
  token:<token from step 2>

Bash

# use '-o yaml' to inspect the output
kubectl create -o yaml -f tokenreview.yaml

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Better StackSponsor

Unified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.

Try Better Stack free →

Mastering Kubernetes Service Accounts: RBAC in Action

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Unifying AI Workloads: KubeCon, OpenInfra, and PyTorch Conference in China

Flipkart's Chaos Engineering Triumph: Scaling Kubernetes with Confidence

Extend Your CKA Certification: The Power of CKS