Ensure Default Service Accounts Are Not Actively Used

Manual Steps

From any machine with kubectl access, list all namespaces and identify which have a default service account using tokens:

kubectl get sa --all-namespaces
kubectl get sa default --all-namespaces -o yaml | grep -E 'name: default$|automountServiceAccountToken'

For each namespace, identify workloads that are implicitly or explicitly using the default service account:
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' | sort
Review pods that show an empty serviceAccountName (implicitly default) or serviceAccountName: default to determine whether they truly need API access.
For pods using the default service account, inspect their specs for explicit token mounting or inherited defaults:
# Example for one pod kubectl -n <namespace> get pod <pod-name> -o yaml | grep -A3 serviceAccount kubectl -n <namespace> get pod <pod-name> -o yaml | grep -i automountServiceAccountToken -n
Decide whether each workload needs Kubernetes API access and, if so, what minimum permissions it needs.

Where workloads require API access, design explicit, least-privilege service accounts and RBAC:

# Example skeleton to adapt per app
kubectl -n <namespace> create serviceaccount <sa-name>
# Then bind minimal roles as appropriate (example only):
kubectl -n <namespace> create role <role-name> --verb=get,list,watch --resource=pods
kubectl -n <namespace> create rolebinding <rb-name> --role=<role-name> --serviceaccount=<namespace>:<sa-name>

Update the corresponding Deployment/StatefulSet/Job manifests to set spec.template.spec.serviceAccountName: <sa-name> and, if needed, automountServiceAccountToken: true there instead of relying on defaults.

After migrating workloads off the default service account in a namespace, disable token automount on that default account:
kubectl -n <namespace> patch serviceaccount default -p $'automountServiceAccountToken: false'
If using GitOps/manifests, ensure the same setting is defined in the ServiceAccount manifest rather than patching only live state.

Verify that:

No workloads are using the default service account except where consciously accepted, and
All default service accounts have token automount disabled:

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' | sort | grep ' default$' || echo "No pods using default SA"
kubectl get sa default --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.automountServiceAccountToken}{"\n"}{end}' | sort

Using kubectl

# 1. List all namespaces and see which ones have a default ServiceAccount
# Run on: any machine with kubectl access
kubectl get serviceaccount default --all-namespaces -o wide

Problem indication:

Every namespace will have a default ServiceAccount; that alone is not an issue.
Note any namespaces where workloads exist and you expect them to use dedicated service accounts instead of default.

# 2. Inspect whether default ServiceAccounts auto-mount tokens
# Run on: any machine with kubectl access
kubectl get serviceaccount default --all-namespaces -o yaml

Problem indication:

automountServiceAccountToken: true (explicit) on a default ServiceAccount is a concern.
Missing automountServiceAccountToken means it inherits from pod spec / cluster defaults; treat as needing review.
Tokens listed under secrets: confirm token creation, but not necessarily active use.

# 3. Find pods that are using the default ServiceAccount
# Run on: any machine with kubectl access
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' \
  | sort

Problem indication:

Any pod where the third column is default is actively using the default ServiceAccount.
Focus on namespaces with sensitive workloads or where API access should be tightly scoped.

# 4. For pods using default SA, check if tokens are being auto-mounted
# Example for all pods, filtering to those with default SA
# Run on: any machine with kubectl access
kubectl get pods --all-namespaces -o json \
  | jq -r '.items[]
    | select(.spec.serviceAccountName=="default")
    | "\(.metadata.namespace)\t\(.metadata.name)\t\(.spec.automountServiceAccountToken)"'

Problem indication:

true means the pod is set to mount a token.
null means it may inherit from the ServiceAccount (or cluster default); requires manual review of both pod and SA.

If jq is not available, inspect specific pods:

# Inspect a specific pod using default SA
# Run on: any machine with kubectl access
kubectl get pod <pod-name> -n <namespace> -o yaml

Problem indication in pod YAML:

spec.serviceAccountName: default AND
spec.automountServiceAccountToken: true (or absent when SA/cluster default is true) AND
A projected service account token volume in spec.volumes or a token under /var/run/secrets/kubernetes.io/serviceaccount.

# 5. Review access granted via default ServiceAccounts (ClusterRoleBinding/RoleBinding)
# Run on: any machine with kubectl access
kubectl get rolebinding,clusterrolebinding --all-namespaces -o yaml \
  | grep -A5 -n "kind: ServiceAccount" | grep -B2 "name: default"

Problem indication:

Any RoleBinding or ClusterRoleBinding whose subjects include:
- kind: ServiceAccount
- name: default
- plus a namespace: value
Especially concerning if bound to powerful Role/ClusterRole (e.g., cluster-admin, broad * verbs/resources).

# 6. (Optional) Summarize which namespaces have default SA bound to roles
# Run on: any machine with kubectl access
kubectl get rolebinding --all-namespaces -o json \
  | jq -r '.items[]
    | . as $rb
    | .subjects[]
    | select(.kind=="ServiceAccount" and .name=="default")
    | "\($rb.metadata.namespace)\t\($rb.metadata.name)\t\($rb.roleRef.kind)\t\($rb.roleRef.name)"'

kubectl get clusterrolebinding -o json \
  | jq -r '.items[]
    | . as $crb
    | .subjects[]
    | select(.kind=="ServiceAccount" and .name=="default")
    | "CLUSTER\t\($crb.metadata.name)\t\($crb.roleRef.kind)\t\($crb.roleRef.name)\tNS:\(.namespace)"'

Problem indication:

Any line returned indicates a default ServiceAccount is granted explicit RBAC permissions.
The more privileged the referenced Role/ClusterRole, the higher the concern.

Use these outputs to decide:

Where new, explicit ServiceAccounts should be created.
Where to stop using default in pod specs.
Where automountServiceAccountToken: false should be set on default ServiceAccounts and/or pods.

Automation

#!/usr/bin/env bash
# Report use and configuration of default service accounts across the cluster.
# Run on: any machine with kubectl access and current-context pointing to the target cluster.

set -o errexit
set -o nounset
set -o pipefail

echo "=== 1) Default ServiceAccount configuration in all namespaces ==="
echo "Namespace,SA,automountServiceAccountToken"
kubectl get sa --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.metadata.name=="default")
    | [
        .metadata.namespace,
        .metadata.name,
        (if .automountServiceAccountToken==true then "true"
         elif .automountServiceAccountToken==false then "false"
         else "null(inherited)" end)
      ]
    | @csv
  '

cat <<'EOF'

Interpretation:
- default SA with "true"      => RISK: explicitly enabled token automount.
- default SA with "null(...)" => RISK: inherits behavior; confirm namespace/pod-level automount.
- default SA with "false"     => Preferred: token automount disabled at SA level.

EOF

echo "=== 2) Pods currently using the default ServiceAccount ==="
echo "Namespace,Pod,ServiceAccount,SA_automount,pod.spec.automountServiceAccountToken"
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.spec.serviceAccountName=="default" or .spec.serviceAccount==null)
    | . as $pod
    | ($pod.spec.serviceAccountName // "default") as $sa
    | $pod.metadata.namespace as $ns
    | (
        ([
          .items[]
          | select(.kind=="ServiceAccount")? # safeguard, usually not present in pod list
        ] | length) as $dummy # no-op
      ) // empty
    ' >/dev/null 2>&1 || true

# We need SA data; fetch separately and join via jq.
pods_json="$(kubectl get pods --all-namespaces -o json)"
sas_json="$(kubectl get sa --all-namespaces -o json)"

jq -rn --argfile pods <(printf '%s\n' "$pods_json") --argfile sas <(printf '%s\n' "$sas_json") '
  $pods.items[]
  | select(.spec.serviceAccountName=="default" or (.spec.serviceAccountName==null and .spec.serviceAccount==null))
  | . as $p
  | ($p.spec.serviceAccountName // "default") as $sa
  | ($sas.items[]
     | select(.metadata.namespace==$p.metadata.namespace and .metadata.name==$sa)
     | .automountServiceAccountToken) as $sa_auto
  | [
      $p.metadata.namespace,
      $p.metadata.name,
      $sa,
      (if $sa_auto==true then "true"
       elif $sa_auto==false then "false"
       else "null(inherited)" end),
      (if $p.spec.automountServiceAccountToken==true then "true"
       elif $p.spec.automountServiceAccountToken==false then "false"
       else "null(unset)" end)
    ]
  | @csv
'

cat <<'EOF'

Interpretation (Pods):
- Any row listed here means a pod is using the "default" ServiceAccount.
- Risk increases when:
  - SA_automount == "true", or
  - SA_automount == "null(inherited)" and pod/spec defaults to automounting, or
  - pod.spec.automountServiceAccountToken == "true".
- Review these workloads and migrate them to explicit ServiceAccounts with least-privilege RBAC.

EOF

echo "=== 3) Namespaces that still bind RBAC directly to the default ServiceAccount ==="
echo "Namespace,RoleBinding,Kind,SubjectKind,SubjectName"
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json \
  | jq -r '
    .items[]
    | . as $rb
    | ($rb.subjects // [])[]
    | select(.kind=="ServiceAccount" and .name=="default")
    | [
        ($rb.metadata.namespace // "cluster-scope"),
        $rb.metadata.name,
        $rb.kind,
        .kind,
        .name
      ]
    | @csv
  '

cat <<'EOF'

Interpretation (RBAC):
- Any line here indicates the "default" ServiceAccount is explicitly granted roles.
- These are high-priority for remediation:
  - Create dedicated ServiceAccounts.
  - Update bindings to reference those instead of "default".
  - Optionally set automountServiceAccountToken: false on default SAs.

EOF

echo "=== 4) Quick summary indicators ==="
echo "- Count of namespaces where default SA does NOT have automountServiceAccountToken=false:"
kubectl get sa --all-namespaces -o json \
  | jq -r '
    [ .items[]
      | select(.metadata.name=="default")
      | select(.automountServiceAccountToken!=false)
      | .metadata.namespace
    ] | unique | length
  '

echo "- Count of pods using the default ServiceAccount:"
kubectl get pods --all-namespaces -o json \
  | jq -r '
    [ .items[]
      | select(.spec.serviceAccountName=="default" or (.spec.serviceAccountName==null and .spec.serviceAccount==null))
    ] | length
  '

cat <<'EOF'

Cluster is closer to compliant when:
- All default ServiceAccounts show automountServiceAccountToken = false.
- The count of pods using the default ServiceAccount is 0 (or only known, accepted exceptions).
- No RoleBinding/ClusterRoleBinding subjects the default ServiceAccount.

EOF

OCI Misconfigurations

Ensure Default Service Accounts Are Not Actively Used

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation