How to Retrieve ServiceAccount Tokens in Kubernetes 1.24+ Without Legacy Secrets
Starting with Kubernetes 1.24, automatic ServiceAccount token Secrets are deprecated; this guide explains the core changes, shows how to manually create token Secrets, extract tokens, and verify permissions using command‑line, API calls, and RBAC inspection, plus common troubleshooting steps.
Since Kubernetes 1.24, the ServiceAccount token management mechanism has changed dramatically: automatic creation of legacy token Secrets is deprecated and the TokenRequest API must be used, with tokens now bound to a configurable lifetime (default 1 hour).
Key Changes
Stop automatic creation of Legacy Token Secret; enforce use of TokenRequest API; token lifecycle is bound (default 1 hour).
Version Comparison
Token generation method: automatic Secret (≤1.23) → manual Token Secret (≥1.24)
Token validity: permanent (≤1.23) → configurable expiration (default 1 h) (≥1.24)
Security features: risk of leakage (≤1.23) → audience‑bound verification (≥1.24)
Practical Token Retrieval
2.1 Create Token Secret template
# sa-token.yaml
apiVersion: v1
kind: Secret
metadata:
name: prom-sa-secret
namespace: kube-system
annotations:
kubernetes.io/service-account.name: "prometheus" # key SA
type: kubernetes.io/service-account-token # token type2.2 Apply configuration and extract token
# Create Secret
kubectl apply -f sa-token.yaml
# Extract Base64‑encoded token
TOKEN=$(kubectl -n kube-system get secret prom-sa-secret -ojsonpath='{.data.token}')Three Ways to Verify Permissions
3.1 Quick CLI verification
# Decode token and view subject
echo $TOKEN | base64 -d | awk -F. '{printf $2}' | base64 -d | python -m json.tool | grep sub
# Expected output:
"sub": "system:serviceaccount:kube-system:prometheus"
# Check node read permission
kubectl auth can-i get nodes --as=system:serviceaccount:kube-system:prometheus
# Check Ingress creation permission (requires RBAC)
kubectl auth can-i create ingress --as=system:serviceaccount:kube-system:prometheus3.2 Simulate API request
# Use curl with the token
curl -k -H "Authorization: Bearer $(echo $TOKEN | base64 -d)" \
https://${API_SERVER}/api/v1/namespaces/kube-system/pods
# Typical responses:
# 200 OK – read permission granted
# 403 Forbidden – insufficient permission3.3 Reverse‑engineer RBAC rules
# Find ClusterRole bound to the ServiceAccount
kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[0].name=="prometheus")'
# Describe the ClusterRole for detailed permissions
kubectl describe clusterrole prometheusCommon Troubleshooting
Issue 1: Secret created but token not generated.
Solution:
Verify the ServiceAccount exists.
Check that the annotation format is correct.
Inspect kube‑controller‑manager logs.
Issue 2: Token returns “Unauthorized”.
Diagnosis:
# Check token expiration timestamp
kubectl get secret prom-sa-secret -o jsonpath='{.metadata.annotations.expiration-timestamp}'
# Verify RBAC bindings
kubectl get rolebinding,clusterrolebinding -A | grep prometheusConclusion
After Kubernetes 1.24, ServiceAccount tokens are no longer generated as Secrets. This guide walks you through manually creating token Secrets, extracting tokens, validating permissions, and troubleshooting common issues.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Linux Ops Smart Journey
The operations journey never stops—pursuing excellence endlessly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
