ServiceAccount
An identity for Pods to authenticate to the Kubernetes API and cloud provider services, with tokens automatically mounted.
What is ServiceAccount?
A ServiceAccount is a Kubernetes identity for processes running inside Pods, as opposed to human users. Every namespace has a default ServiceAccount; every Pod is automatically assigned the default ServiceAccount unless another is specified. The kubelet mounts a ServiceAccount token into the Pod at /var/run/secrets/kubernetes.io/serviceaccount/token, enabling in-cluster code to authenticate to the Kubernetes API using that token's RBAC permissions.
Modern Kubernetes (1.22+) uses projected ServiceAccount tokens with configurable expiry (default 1 hour) instead of long-lived static tokens, significantly reducing the risk of token theft. For accessing cloud provider APIs — AWS IAM, GCP IAM, Azure AAD — ServiceAccounts can be linked to cloud IAM roles via Workload Identity (GKE), IRSA (EKS), or Workload Identity Federation (AKS), enabling fine-grained cloud API access without storing cloud credentials in Secrets.
The principle of least privilege applies directly to ServiceAccounts: each workload should have its own ServiceAccount with only the permissions it needs. Using the default ServiceAccount for application Pods is an anti-pattern that means all Pods in the namespace share the same identity and RBAC permissions.
Example
# Create a dedicated service account for an app
kubectl create serviceaccount web-api -n production
# Bind a role to the service account
kubectl create rolebinding web-api-reader \
--role=pod-reader \
--serviceaccount=production:web-api \
-n production
# Check what a ServiceAccount can do
kubectl auth can-i --list \
--as=system:serviceaccount:production:web-api \
-n productionCost & Waste Implications
Orphaned ServiceAccounts (not referenced by any running Pod) with bound RBAC permissions represent persistent attack surface with no operational benefit. If an orphaned ServiceAccount token is extracted from a stored kubeconfig or CI secret, an attacker can use it to interact with the Kubernetes API indefinitely until the ServiceAccount is deleted.
How KorPro Helps
KorPro detects ServiceAccounts with no active Pod references and reports their RBAC permission scope, helping security teams identify and revoke stale identities before they become attack vectors.
Scan Your Cluster FreeRelated Terms
RBAC(RBAC)
SecurityRole-Based Access Control — Kubernetes's authorization mechanism that grants permissions through role bindings.
Read definitionRole and ClusterRole
SecurityRBAC objects that define a set of permitted API verbs on specified resources, scoped to a namespace (Role) or cluster-wide (ClusterRole).
Read definitionPod Security
SecurityKubernetes controls that restrict what Pods can do at the OS level — capabilities, root access, host namespaces, and file system permissions.
Read definitionSecret
ConfigurationAn API object for storing sensitive data such as passwords, tokens, and TLS certificates, base64-encoded in etcd.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.