Prefer Using Dedicated Amazon EKS Service Accounts

#!/usr/bin/env bash
#
# Audit EKS IRSA usage and pods relying on node IAM roles
# Run on: any machine with kubectl access and AWS CLI configured
#
# Requirements:
#   - kubectl
#   - jq
#   - aws (optional but recommended for CloudTrail/IAM checks)

set -euo pipefail

echo "=== 1) Cluster-wide summary of service accounts and IRSA usage ==="

# List all service accounts and whether they have an IAM role annotated
kubectl get sa --all-namespaces -o json \
  | jq -r '
    [
      "NAMESPACE",
      "SERVICE_ACCOUNT",
      "HAS_IRSA_ROLE",
      "IAM_ROLE_ARN"
    ],
    (
      .items[]
      | {
          ns: .metadata.namespace,
          name: .metadata.name,
          role: (.metadata.annotations["eks.amazonaws.com/role-arn"] // "")
        }
      | [
          .ns,
          .name,
          (if .role == "" then "no" else "yes" end),
          .role
        ]
    )
    | @tsv
  ' \
  | column -t

echo
echo "=== 2) Pods that are using a given service account (and whether that SA has IRSA) ==="

# Join pods with their service account and IRSA role annotation
kubectl get pods --all-namespaces -o json \
  | jq -r '
    [
      "NAMESPACE",
      "POD",
      "SERVICE_ACCOUNT",
      "SA_HAS_IRSA_ROLE",
      "SA_IAM_ROLE_ARN"
    ],
    (
      .items[]
      | {
          ns: .metadata.namespace,
          pod: .metadata.name,
          sa: (.spec.serviceAccountName // "default")
        }
      | . + {
          sa_role: (
            (input.items[]
              | select(.metadata.namespace == .ns and .metadata.name == .sa)
            )? # may be null if SA deleted
          )
        }
      # We actually feed SA list via --slurpfile below
    )
  ' 2>/dev/null || true

echo "Collecting service accounts with IRSA annotation..."
SA_TMP="$(mktemp)"
kubectl get sa --all-namespaces -o json \
  | jq -r '
    .items[]
    | [
        .metadata.namespace,
        .metadata.name,
        (.metadata.annotations["eks.amazonaws.com/role-arn"] // "")
      ]
    | @tsv
  ' > "${SA_TMP}"

echo -e "NAMESPACE\tPOD\tSERVICE_ACCOUNT\tSA_HAS_IRSA_ROLE\tSA_IAM_ROLE_ARN"
kubectl get pods --all-namespaces -o json \
  | jq -r '
      .items[]
      | [
          .metadata.namespace,
          .metadata.name,
          (.spec.serviceAccountName // "default")
        ]
      | @tsv
    ' \
  | while IFS=$'\t' read -r NS POD SA; do
      SA_LINE="$(awk -v ns="$NS" -v sa="$SA" '$1 == ns && $2 == sa' "${SA_TMP}" || true)"
      SA_ROLE_ARN="$(cut -f3 <<<"$SA_LINE" 2>/dev/null || true)"
      if [ -n "$SA_ROLE_ARN" ]; then
        HAS_IRSA="yes"
      else
        HAS_IRSA="no"
      fi
      printf "%s\t%s\t%s\t%s\t%s\n" "$NS" "$POD" "$SA" "$HAS_IRSA" "$SA_ROLE_ARN"
    done \
  | column -t

rm -f "${SA_TMP}"

echo
echo "=== 3) Pods that likely rely on node IAM role instead of IRSA ==="
echo "Heuristic: pods whose service account has no eks.amazonaws.com/role-arn annotation."

kubectl get pods --all-namespaces -o json \
  | jq -r '
      .items[]
      | [
          .metadata.namespace,
          .metadata.name,
          (.spec.serviceAccountName // "default")
        ]
      | @tsv
    ' \
  | while IFS=$'\t' read -r NS POD SA; do
      ROLE_ANNOTATION="$(
        kubectl get sa "$SA" -n "$NS" -o json 2>/dev/null \
          | jq -r ".metadata.annotations[\"eks.amazonaws.com/role-arn\"] // \"\""
      )"
      if [ -z "$ROLE_ANNOTATION" ]; then
        printf "%s\t%s\t%s\n" "$NS" "$POD" "$SA"
      fi
    done \
  | {
      echo -e "NAMESPACE\tPOD\tSERVICE_ACCOUNT"
      column -t
    }

echo
echo "=== 4) Optional: identify pods that are likely calling AWS APIs ==="
echo "NOTE: This is heuristic-only, based on common AWS env vars and images."

kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | . as $pod
    | [
        $pod.metadata.namespace,
        $pod.metadata.name,
        ($pod.spec.serviceAccountName // "default"),
        (
          [
            ($pod.spec.containers[]?.image // "")
          ]
          | join(",")
        ),
        (
          [
            ($pod.spec.containers[]?.env[]? | select(.name|test("AWS_|AMAZON_")) | .name)
          ]
          | unique
          | join(",")
        )
      ]
    | @tsv
  ' \
  | {
      echo -e "NAMESPACE\tPOD\tSERVICE_ACCOUNT\tIMAGES\tAWS_RELATED_ENV_VARS"
      column -t -s $'\t'
    }

echo
echo "=== Interpretation guidance ==="
cat <<'EOF'
Findings that likely indicate a problem relative to the benchmark intent:

1) Service accounts with no IRSA role:
   - In section (1), any service account with HAS_IRSA_ROLE = "no" that is
     used by applications calling AWS APIs is a review candidate.

2) Pods using service accounts without IRSA:
   - In section (2) and (3), pods where SA_HAS_IRSA_ROLE = "no" are probably
     using the shared node IAM role if they call AWS services, which goes
     against the recommendation to prefer dedicated EKS service accounts
     with IAM roles (IRSA).

3) Pods likely calling AWS APIs but without IRSA:
   - In section (4), look for pods that:
       * Have AWS_RELATED_ENV_VARS set (e.g., AWS_REGION, AWS_ACCESS_KEY_ID),
         or
       * Use images known to interact with AWS (custom app images, tools like
         awscli, fluent-bit with S3/CloudWatch outputs, etc.)
     and then check whether their service account in earlier sections has
     HAS_IRSA_ROLE = "yes".
   - If such pods use a service account without an IAM role annotation, they
     likely rely on the node IAM role and should be reviewed.

This script only reports current state. Moving workloads from node IAM roles
to IRSA requires:
  - Creating IAM roles and policies for each service account,
  - Annotating the service accounts with eks.amazonaws.com/role-arn, and
  - Ensuring pods use those service accounts.
Those steps must be designed and applied manually (or via IaC) with
least-privilege in mind.
EOF