Service Account Token Authentication Should Not Be Used For Users

#!/usr/bin/env bash
#
# Purpose:
#   Report potential *user* use of service account tokens across the cluster.
#   This is for review only; it does NOT attempt to fix or definitively prove compliance.
#
# Requirements:
#   - Run on any machine with kubectl access and cluster-wide RBAC rights to:
#       * list serviceaccounts, secrets, pods, events, and audit logs (if enabled)
#   - kubectl must be configured (KUBECONFIG or in-cluster config).

set -euo pipefail

NL=$'\n'

header() {
  echo
  echo "=== $1 ==="
}

###############################################################################
# 1. Detect SA tokens mounted into Pods that look like *interactive user* pods
###############################################################################
header "1) Pods with service account tokens mounted (cluster-wide)"

# This shows all pods with the standard SA token mount path.
# Service accounts are expected for workloads; flag namespaces/pods that look like user environments.
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\t"}{range .spec.volumes[*]}{.name}{"="}{.projected.sources[*].serviceAccountToken.path}{";"}{end}{"\n"}{end}' \
  | awk -F'\t' '
    NF==4 {
      ns=$1; pod=$2; sa=$3; vols=$4
      if (vols ~ /token/ || vols ~ /serviceaccount/ || vols ~ /sa-token/) {
        print ns "\t" pod "\t" sa "\t" vols
      }
    }
  ' \
  | column -t || true

cat <<EOF

Review guidance:
- NORMAL for workloads to have SA tokens.
- POTENTIAL ISSUE if:
  - Namespace or pod names suggest interactive/user use, e.g.: "user", "dev-shell", "jumpbox", "bastion",
    "notebook", "jupyter", "workspace", or personal names.
  - ServiceAccountName suggests user identity, e.g. "alice", "bob", "team-x-user".
These indicate service account tokens might be used as user credentials instead of OIDC.
EOF

###############################################################################
# 2. ServiceAccounts that appear to represent *users*
###############################################################################
header "2) ServiceAccounts that look like user identities"

kubectl get sa -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.metadata.annotations}{"\n"}{end}' \
  | awk -F'\t' '
    {
      ns=$1; sa=$2; ann=$3
      lower=tolower(sa)
      if (lower ~ /user/ || lower ~ /login/ || lower ~ /human/ ||
          lower ~ /jupyter/ || lower ~ /notebook/ ||
          lower ~ /alice/ || lower ~ /bob/ || lower ~ /dev-.*-shell/ ) {
        print ns "\t" sa "\t" ann
      }
    }
  ' \
  | column -t || true

cat <<EOF

Review guidance:
- NORMAL for SAs to be workload-specific names (e.g. "nginx", "controller", "ci-runner").
- POTENTIAL ISSUE if SAs appear to model human users (names, emails, "user", "login", etc.),
  especially when bound to broad RBAC roles. This suggests user identities may rely on SA tokens.
EOF

###############################################################################
# 3. Secrets that are or were service account tokens
###############################################################################
header "3) ServiceAccount token secrets (cluster-wide)"

# Kubernetes v1.24+ typically uses projected SA tokens; older clusters used Secret-type tokens.
# This lists any classic token secrets that could be directly exfiltrated/used.
kubectl get secrets -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.type}{"\t"}{.metadata.annotations}{"\n"}{end}' \
  | awk -F'\t' '
    {
      ns=$1; name=$2; type=$3; ann=$4
      if (type ~ /kubernetes.io\/service-account-token/) {
        print ns "\t" name "\t" type "\t" ann
      }
    }
  ' \
  | column -t || true

cat <<EOF

Review guidance:
- NORMAL in older clusters to have many kubernetes.io/service-account-token secrets.
- POTENTIAL ISSUE if:
  - These secrets are referenced outside Pods (e.g., given directly to users, external tools,
    or checked into source control).
  - Annotations or names suggest human users or external non-workload usage.
Manual investigation needed to see if humans are authenticating with these tokens.
EOF

###############################################################################
# 4. (If audit logs available) Look for bearer-token auth using SA tokens
###############################################################################
header "4) (Optional) Audit log indications of SA token authentication"

cat <<'EOF'
If Kubernetes API audit logs are enabled and accessible, search for use of service
account bearer tokens as user authentication.

Examples (run on the machine that has access to audit logs, adjust paths/commands):

  # Example: GREP for 'system:serviceaccount' subjects in audit logs
  sudo find /var/log -type f -name '*kube-apiserver-audit*' -print0 \
    | xargs -0 grep -H "system:serviceaccount" | head

  # Example: If logs in JSON, extract subjects that might represent "users" via jq
  sudo find /var/log -type f -name '*kube-apiserver-audit*' -print0 \
    | xargs -0 jq -r '
        select(.user.username | startswith("system:serviceaccount:")) |
        .user.username
      ' | sort -u

Review guidance:
- NORMAL: service accounts are used by workloads; you will see system:serviceaccount:* identities.
- POTENTIAL ISSUE:
  - Requests from unusual source IPs corresponding to user networks/laptops/VPNs.
  - Long-lived tokens reused from many locations that map to "user-like" SAs.
  - Evidence that humans are using curl/kubectl with "Authorization: Bearer <SA token>" instead of OIDC.

There is no one-shot automated remediation:
- Use this evidence to decide:
  - Which service accounts must be migrated off for human use.
  - How to introduce/require OIDC for user authentication.
EOF

###############################################################################
# Summary of what indicates a PROBLEM
###############################################################################
header "5) Quick interpretation summary"

cat <<EOF
Potential problems to investigate further:

1) Pods in user-like namespaces or with user-like names that have service account tokens mounted.
2) ServiceAccounts with names/annotations that represent human users or logins.
3) ServiceAccount token secrets used outside normal pod mounting (e.g., handed to users/tools).
4) Audit log entries showing serviceaccount identities coming from user endpoints
   or being used as long-lived user credentials.

This script only surfaces *signals*; you must manually confirm whether humans are
authenticating with service account tokens instead of using OIDC.
EOF