Prefer Bound Projected ServiceAccount Tokens Over Secret Tokens

# 1. List all long-lived ServiceAccount token Secrets
# Run on: any machine with kubectl access
kubectl get secrets -A --field-selector type=kubernetes.io/service-account-token

# 2. For a specific token Secret, inspect details
# Replace NAMESPACE and SECRET_NAME with values from the list above
kubectl -n NAMESPACE get secret SECRET_NAME -o yaml

# 3. List ServiceAccounts in an application namespace
# Replace NAMESPACE with your app namespace (not kube-system)
kubectl -n NAMESPACE get serviceaccounts

# 4. For a given ServiceAccount, see its Secrets and automount setting
kubectl -n NAMESPACE get serviceaccount SERVICEACCOUNT_NAME -o yaml

# 5. Find Pods that mount ServiceAccount token Secrets directly
kubectl -n NAMESPACE get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.volumes[*].secret.secretName}{"\n"}{end}' | grep -v '^\s*$'

# 6. Inspect a Pod spec for how it gets its token
kubectl -n NAMESPACE get pod POD_NAME -o yaml

# 7. (Optional) Check if a ServiceAccount token Secret is actually referenced by any Pod
# Replace NAMESPACE with the namespace you are reviewing
for s in $(kubectl -n NAMESPACE get secrets --field-selector type=kubernetes.io/service-account-token -o jsonpath='{.items[*].metadata.name}'); do
  echo "Secret: $s"
  kubectl -n NAMESPACE get pods -o jsonpath="{range .items[*]}{.metadata.name}{': '}{range .spec.volumes[*]}{.secret.secretName}{','}{end}{'\n'}{end}" | grep "$s" || echo "  (no pods referencing this secret)"
  echo
done

#!/usr/bin/env bash
# Report long-lived ServiceAccount token Secrets and their usage (GKE)
# Run on: any machine with kubectl access and appropriate RBAC

set -euo pipefail

echo "=== ServiceAccount token Secrets (type=kubernetes.io/service-account-token) ==="
kubectl get secrets -A \
  --field-selector type=kubernetes.io/service-account-token \
  -o json \
| jq -r '
  .items[]
  | {
      ns: .metadata.namespace,
      name: .metadata.name,
      sa: .metadata.annotations["kubernetes.io/service-account.name"],
      created: .metadata.creationTimestamp,
      # Approximate size of the JWT; very large tokens may indicate legacy/default tokens
      token_bytes: (.data.token // "" | @base64d | length),
      # In GKE, bound tokens typically have an "kubernetes.io/service-account.uid" annotation;
      # presence alone does NOT guarantee projected/bound usage, but absence is a red flag.
      sa_uid: .metadata.annotations["kubernetes.io/service-account.uid"]
    }
  | @tsv
' \
| awk 'BEGIN {
         OFS="\t";
         print "NAMESPACE","SECRET","SERVICEACCOUNT","CREATED","TOKEN_BYTES","SA_UID_PRESENT"
       }
       {
         sa_uid = ($6 == "" ? "no" : "yes");
         print $1,$2,$3,$4,$5,sa_uid
       }'

echo
echo "=== Pods that mount ServiceAccount token Secrets directly as volumes ==="
# Pods that explicitly mount a SA token Secret instead of using the default
# projected token volume are higher risk.
kubectl get pods -A -o json \
| jq -r '
  .items[]
  | {
      ns: .metadata.namespace,
      pod: .metadata.name,
      sa: .spec.serviceAccountName,
      vols: .spec.volumes
    }
  | select(.vols != null)
  | .vols[]
  | select(.secret != null)
  | {
      ns: input.ns,
      pod: input.pod,
      sa: input.sa,
      vol_name: .name,
      secret_name: .secret.secretName
    }
  | @tsv
' 2>/dev/null \
| awk 'BEGIN {
         OFS="\t";
         print "NAMESPACE","POD","SERVICEACCOUNT","VOLUME_NAME","SECRET_NAME"
       }
       { print }'

echo
echo "=== Pods using default ServiceAccount token projection ==="
# These pods rely on the projected token volume mechanism, which is preferred.
kubectl get pods -A -o json \
| jq -r '
  .items[]
  | {
      ns: .metadata.namespace,
      pod: .metadata.name,
      sa: .spec.serviceAccountName,
      automount: (.spec.automountServiceAccountToken // "default"),
      projected: (
        .spec.volumes // []
        | map(select(.projected != null))
        | map(
            .projected.sources // []
            | map(select(.serviceAccountToken != null))
            | length
          )
        | add
      )
    }
  | select(.projected > 0 or .automount != false)
  | @tsv
' \
| awk 'BEGIN {
         OFS="\t";
         print "NAMESPACE","POD","SERVICEACCOUNT","AUTOMOUNT_SA_TOKEN","NUM_PROJECTED_SA_TOKEN_SOURCES"
       }
       { print }'

cat <<'EOF'

INTERPRETING THE OUTPUT (WHAT INDICATES A PROBLEM):

1) "ServiceAccount token Secrets" table:
   - Any row is a potential concern: long-lived Secrets of type
     "kubernetes.io/service-account-token" exist.
   - "SA_UID_PRESENT = no" is a stronger red flag (likely older-style token Secret).
   - Very old "CREATED" timestamps suggest long-lived tokens that should be rotated away.
   - Large "TOKEN_BYTES" values are normal for JWTs; focus on existence and age rather than size.

2) "Pods that mount ServiceAccount token Secrets directly as volumes":
   - Any row here is a concern: the pod is explicitly mounting a ServiceAccount token Secret,
     which tends to create long-lived, broadly scoped credentials.

3) "Pods using default ServiceAccount token projection":
   - Preferred pattern is: AUTONMOUNT_SA_TOKEN = true or "default",
     and NUM_PROJECTED_SA_TOKEN_SOURCES > 0, with application logic using TokenRequest
     (projected) tokens with audience+expiry.
   - This report only shows presence of projected token sources; you still need to review
     app code/manifests to confirm that TokenRequest-style tokens are used correctly.

This script does not change any resources. Use it periodically to identify
namespaces/ServiceAccounts/Pods that still rely on long-lived ServiceAccount token Secrets
and prioritize them for manual refactoring to projected, short-lived tokens.
EOF