Kubernetes Service Accounts Admin: Essential Commands with Practical Examples

Introduction

Kubernetes service accounts are a foundational part of cluster security, providing an identity for processes running in pods. They are not user accounts; instead, they are used by applications to authenticate against the Kubernetes API or external services. As a cluster administrator or DevOps engineer, understanding how to create, inspect, and manage service accounts is critical to securing your workloads and ensuring smooth operations.

This guide offers a practical collection of kubectl commands and workflows for administering service accounts. It covers the basics such as creating a service account, listing and inspecting it, and managing associated tokens and secrets. It then dives into role-based access control (RBAC) binding, pod integration, and troubleshooting. Each section includes concrete command examples, expected outputs, and guidance on what to do when things go wrong.

Whether you are preparing for the Certified Kubernetes Administrator (CKA) exam or managing production clusters, these commands form the core of your daily operational toolset. By the end of this guide, you will be able to confidently manage service accounts, diagnose authentication failures, and implement least-privilege access for your applications.

Version and Environment Inventory

Before running any service account commands, confirm your environment. The examples in this guide assume a Kubernetes cluster running version 1.20 or later, as the token request API and bound service account tokens became stable around that time. Always check your cluster version:

kubectl version --short

Expected output (example):

Client Version: v1.25.0
Server Version: v1.25.3

Also verify that you have the necessary permissions to manage service accounts. Typically, you need cluster-admin or a role that grants create, get, list, watch, and delete on serviceaccounts and secrets in the relevant namespaces. If you are using a managed Kubernetes service like EKS, GKE, or AKS, ensure your IAM or cloud identity is mapped to a Kubernetes role with those rights.

A quick sanity check is to list all service accounts in the default namespace:

kubectl get serviceaccounts

Expected output:

NAME      SECRETS   AGE
default   1         15d

The default service account exists in every namespace and is automatically mounted to pods unless a specific service account is assigned. For production workloads, avoid using the default service account; create a dedicated one with minimal permissions.

Creating a Service Account

Creating a service account is straightforward. Use the imperative command:

kubectl create serviceaccount my-app-sa

Expected output:

serviceaccount/my-app-sa created

To create it declaratively, save the following YAML as sa.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default

Then apply:

kubectl apply -f sa.yaml

After creation, inspect the service account to see its details:

kubectl get serviceaccount my-app-sa -o yaml

In Kubernetes 1.24+, service accounts no longer automatically get a long-lived token secret. Instead, tokens are obtained via the TokenRequest API or by creating a secret of type kubernetes.io/service-account-token manually. You can still create a secret for compatibility:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: my-app-sa-token
  annotations:
    kubernetes.io/service-account.name: my-app-sa
type: kubernetes.io/service-account-token
EOF

However, retrieving a token from a Secret is a legacy mechanism and not recommended. The current approach is to request a short-lived token directly:

kubectl create token my-app-sa

This prints a token to stdout. Treat this token as sensitive; never log it or commit it to version control. For additional token management options, see the Managing Secrets and Tokens section.

Listing and Inspecting Service Accounts

Listing all service accounts across all namespaces:

kubectl get serviceaccounts --all-namespaces

To get detailed information about a specific service account:

kubectl describe serviceaccount my-app-sa

Output example:

Name:                my-app-sa
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   my-app-sa-token
Tokens:              my-app-sa-token
Events:              <none>

This shows which secrets are associated and any image pull secrets attached.

Managing Secrets and Tokens

As of Kubernetes 1.24, the recommended approach is to use short-lived tokens via the TokenRequest API. You can request a token for a service account using kubectl:

kubectl create token my-app-sa

This prints a token to stdout. You can specify a duration (default 1 hour):

kubectl create token my-app-sa --duration=2h

For long-lived tokens (not recommended for production), create a secret as shown earlier. To list secrets associated with a service account:

kubectl get secrets --field-selector type=kubernetes.io/service-account-token

To revoke a token, delete the secret:

kubectl delete secret my-app-sa-token

Then the service account will no longer have that token available.

Role-Based Access Control (RBAC)

Service accounts by themselves have no permissions unless bound to roles. To grant access, create a Role or ClusterRole and bind it to the service account.

Example: Grant read-only access to pods in the default namespace.

Create a Role:

kubectl create role pod-reader --verb=get,list,watch --resource=pods

Create a RoleBinding:

kubectl create rolebinding pod-reader-binding --role=pod-reader --serviceaccount=default:my-app-sa

Now the service account can list pods in the default namespace. To verify, you can impersonate the service account in a test:

kubectl auth can-i list pods --as=system:serviceaccount:default:my-app-sa

Expected output:

yes

For cluster-wide permissions, use ClusterRole and ClusterRoleBinding:

kubectl create clusterrole secret-reader --verb=get,list --resource=secrets
kubectl create clusterrolebinding secret-reader-binding --clusterrole=secret-reader --serviceaccount=default:my-app-sa

Always follow least privilege: only grant the permissions needed for the application to function.

Using Service Accounts in Pods

To use a specific service account in a pod, set serviceAccountName in the pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: app
    image: nginx

When the pod runs, the service account token is mounted at /var/run/secrets/kubernetes.io/serviceaccount. You can disable automounting of the token by setting automountServiceAccountToken: false in the pod spec, which is recommended if the pod does not need to talk to the API server.

To check which service account a running pod uses:

kubectl get pod my-app -o jsonpath='{.spec.serviceAccountName}'

Troubleshooting Service Account Issues

Common problems include pods failing to authenticate, missing permissions, and token expiration. Here are steps to diagnose.

Pod cannot authenticate to the API server

• Check that the service account token is mounted:

kubectl exec my-app -- ls /var/run/secrets/kubernetes.io/serviceaccount

Expected output includes token, ca.crt, and namespace.

• If the token is missing, verify that automountServiceAccountToken is not set to false, and that the service account exists and has a secret token (if relying on legacy tokens).

Permission denied when the pod tries to access resources

• Check the roles bound to the service account:

kubectl get rolebindings,clusterrolebindings -o wide | grep my-app-sa

• Use kubectl auth can-i to test permissions as the service account:

kubectl auth can-i get pods --as=system:serviceaccount:default:my-app-sa

If it returns no, you need to adjust the RoleBinding or ClusterRoleBinding.

Token expired or invalid

For legacy long-lived tokens, check the secret's expiration if set. For short-lived tokens, they expire after the requested duration, so the application must request a new token via the TokenRequest API. Consider using client libraries that handle token refresh automatically.

Common Pitfalls and How to Avoid Them

1. Using the default service account

• Why: It is easy to forget to specify a service account, so the default is used, which often has minimal permissions or, if modified, too many.
• How to avoid: Always set serviceAccountName in pod specs, and regularly audit which service accounts pods are using.

1. Overly permissive RBAC roles

• Why: Developers may request broad permissions to avoid troubleshooting later.
• How to avoid: Enforce least privilege, use namespace-scoped roles where possible, and conduct regular access reviews.

1. Hardcoding tokens in application code

• Why: Instead of reading from the mounted service account token file, developers might copy the token into code for testing and forget to remove it.
• How to avoid: Never hardcode tokens; use the in-cluster configuration that reads from the token file, and revoke any leaked tokens immediately.

1. Not rotating legacy tokens

• Why: Long-lived tokens can remain valid indefinitely if not managed.
• How to avoid: Use short-lived tokens via TokenRequest, or set an expiration on manually created secret tokens and rotate them regularly.

Operational Checklist for Service Account Administration

• [ ] Verify cluster version supports the token request API (1.20+).
• [ ] List existing service accounts and identify any unused ones for cleanup.
• [ ] Create dedicated service accounts for each application or workload.
• [ ] Bind least-privilege roles to service accounts using RoleBindings (namespace) or ClusterRoleBindings (cluster-wide).
• [ ] Test permissions with kubectl auth can-i --as=system:serviceaccount:<ns>:<sa>.
• [ ] Configure pods to use the correct service account and disable automount if not needed.
• [ ] Prefer short-lived tokens over long-lived secrets.
• [ ] Regularly audit service account usage and RBAC bindings (e.g., monthly).
• [ ] Document the owner and purpose of each service account in annotations or external documentation. For example: kubectl annotate serviceaccount my-app-sa owner=team-a purpose=api-access.
• [ ] Set up monitoring and alerting for service account token creation and usage anomalies.

Assign a single accountable owner for service account management in your organization, such as a platform engineer or security administrator, and review the entire inventory quarterly.

Conclusion

Managing Kubernetes service accounts effectively is essential for securing your cluster and ensuring that applications have the right level of access. The commands and workflows in this guide cover the full lifecycle: creation, inspection, RBAC binding, pod integration, and troubleshooting. By following the best practices of least privilege, short-lived tokens, and regular audits, you reduce the risk of credential misuse and improve operational hygiene.

Start by auditing your current service accounts, then implement the checklist incrementally. With a solid understanding of these administrative commands, you will be well-equipped to handle service account-related tasks in any Kubernetes environment.