Key Concepts
ServiceAccount
A namespace-scoped identity for pods to authenticate with the Kubernetes API and external services.
Secrets
Tokens and credentials automatically mounted into pods using the ServiceAccount.
ImagePullSecrets
Credentials for pulling container images from private registries.
Auto Mount
Whether to automatically mount the ServiceAccount token into pods.
ServiceAccounts are namespace-scoped resources. Each namespace has a
default ServiceAccount that is automatically assigned to pods that don’t specify one.Required Permissions
| Action | Permission |
|---|---|
| View ServiceAccounts | iam:project:infrastructure:kubernetes:read |
| Create ServiceAccount | iam:project:infrastructure:kubernetes:write |
| Edit ServiceAccount | iam:project:infrastructure:kubernetes:write |
| Delete ServiceAccount | iam:project:infrastructure:kubernetes:delete |
ServiceAccount Types
| Type | Description |
|---|---|
| System | Built-in accounts (named default or prefixed with system:) |
| Custom | User-created ServiceAccounts |
How to View ServiceAccounts
How to View ServiceAccount Details
Review Details
View ServiceAccount information including:
- Overview: Name, namespace, type (system/custom), age
- Secrets: List of associated secrets with token data
- ImagePullSecrets: Registry credentials for pulling images
- Auto Mount: Whether tokens are automatically mounted
- Labels & Annotations: Metadata attached to the ServiceAccount
How to Create a ServiceAccount
Write YAML
Enter the ServiceAccount manifest in YAML format. Key fields:
metadata.name- ServiceAccount namemetadata.namespace- Target namespaceautomountServiceAccountToken- Whether to auto-mount tokensimagePullSecrets- Optional registry credentials
How to Edit a ServiceAccount
Modify Configuration
Edit the ServiceAccount. You can modify:
automountServiceAccountTokenimagePullSecrets- Labels and annotations
How to Delete a ServiceAccount
Example ServiceAccounts
Basic ServiceAccount
Disable Auto-Mount Token
With ImagePullSecrets
Full Configuration
Key Fields
| Field | Description | Default |
|---|---|---|
| automountServiceAccountToken | Auto-mount API token into pods | true |
| secrets | Tokens for API authentication | Auto-generated |
| imagePullSecrets | Credentials for private registries | None |
Auto Mount Token
TheautomountServiceAccountToken field controls whether the ServiceAccount token is automatically mounted into pods:
| Setting | Behavior |
|---|---|
true (default) | Token mounted at /var/run/secrets/kubernetes.io/serviceaccount |
false | No automatic token mount (more secure for pods that don’t need API access) |
Troubleshooting
Pod cannot pull images from private registry
Pod cannot pull images from private registry
- Verify the ServiceAccount has the correct imagePullSecrets
- Check the Secret exists and contains valid registry credentials
- Ensure the pod spec references the ServiceAccount
- Verify the registry URL in the Secret matches the image reference
Pod cannot authenticate with Kubernetes API
Pod cannot authenticate with Kubernetes API
- Check
automountServiceAccountTokenis not set tofalse - Verify RoleBindings/ClusterRoleBindings exist for the ServiceAccount
- Check if the token Secret exists and is valid
- Verify the ServiceAccount exists in the pod’s namespace
Cannot delete ServiceAccount
Cannot delete ServiceAccount
- The
defaultServiceAccount cannot be deleted - Verify you have delete permission
- Check if pods are still using this ServiceAccount
Token not mounted in pod
Token not mounted in pod
- Check
automountServiceAccountTokenat both ServiceAccount and Pod spec levels - Pod spec setting overrides ServiceAccount setting
- Verify the ServiceAccount is correctly referenced in the pod
ServiceAccount token expired or invalid
ServiceAccount token expired or invalid
- Kubernetes 1.24+ uses bound service account tokens with expiration
- Tokens are automatically refreshed by the kubelet
- For long-running processes, ensure proper token refresh handling
- Consider using projected volumes for token configuration
Permissions not working after binding
Permissions not working after binding
- Verify the RoleBinding/ClusterRoleBinding references the correct ServiceAccount
- Check the namespace is correct in the binding’s subject
- Use
kubectl auth can-i --as=system:serviceaccount:<namespace>:<name>to test
FAQ
What is the default ServiceAccount?
What is the default ServiceAccount?
Every namespace automatically has a
default ServiceAccount. Pods that don’t specify a ServiceAccount use this one. It has minimal permissions by default and cannot be deleted.How do I grant permissions to a ServiceAccount?
How do I grant permissions to a ServiceAccount?
Create a RoleBinding or ClusterRoleBinding that binds the ServiceAccount to a Role or ClusterRole:
Should I create separate ServiceAccounts for each application?
Should I create separate ServiceAccounts for each application?
Yes. Each application should have its own ServiceAccount with only the permissions it needs. This follows the principle of least privilege and limits the blast radius if an application is compromised.
What are imagePullSecrets used for?
What are imagePullSecrets used for?
ImagePullSecrets provide credentials for pulling container images from private registries. When a pod uses a ServiceAccount with imagePullSecrets, those credentials are automatically used to pull images.
When should I disable automountServiceAccountToken?
When should I disable automountServiceAccountToken?
Disable auto-mount when:
- The pod doesn’t need to access the Kubernetes API
- You want to improve security by not exposing credentials
- You’re using a different authentication method
automountServiceAccountToken: false on the ServiceAccount or in the pod spec.How are ServiceAccount tokens managed in Kubernetes 1.24+?
How are ServiceAccount tokens managed in Kubernetes 1.24+?
Starting with Kubernetes 1.24:
- Tokens are no longer auto-generated as Secrets
- Bound service account tokens are created on-demand with expiration
- Tokens are automatically refreshed by the kubelet
- Legacy token Secrets are not created by default
Can a pod use a ServiceAccount from another namespace?
Can a pod use a ServiceAccount from another namespace?
No. A pod can only use a ServiceAccount from its own namespace. To grant cross-namespace permissions, use ClusterRoleBindings or create identical ServiceAccounts in each namespace.
How do I check what permissions a ServiceAccount has?
How do I check what permissions a ServiceAccount has?
Use kubectl to test permissions:Or check all RoleBindings/ClusterRoleBindings that reference the ServiceAccount.