Prefer Using Dedicated Amazon Eks Service Accounts

#!/usr/bin/env bash
# Report pods that may be using node IAM roles instead of dedicated IRSA roles
# Run on: any machine with kubectl access and AWS CLI configured
# Requirements: kubectl, jq, aws

set -euo pipefail

# --- configuration (edit as needed) ---
# Namespace(s) to include; leave empty for all namespaces
NAMESPACES=""     # e.g. "default kube-system app-namespace"
# Known service accounts that SHOULD have IRSA roles (optional allowlist)
KNOWN_IRSA_SA=""  # e.g. "kube-system:external-dns prod:app-sa"

echo "== Detect pods likely using node IAM roles (no IRSA) ==" >&2

# Helper: list namespaces
if [[ -z "${NAMESPACES}" ]]; then
  mapfile -t NS_LIST < <(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}')
else
  read -ra NS_LIST <<< "${NAMESPACES}"
fi

tmpdir="$(mktemp -d)"
trap 'rm -rf "${tmpdir}"' EXIT

# 1. Identify service accounts that are configured for IRSA (have eks.amazonaws.com/role-arn)
echo "== ServiceAccounts with IRSA annotation (eks.amazonaws.com/role-arn) =="

for ns in "${NS_LIST[@]}"; do
  kubectl get sa -n "${ns}" -o json \
  | jq -r --arg ns "${ns}" '
      .items[]
      | select(.metadata.annotations["eks.amazonaws.com/role-arn"] != null)
      | "\($ns):\(.metadata.name) -> \(.metadata.annotations["eks.amazonaws.com/role-arn"])"
    ' || true
done | tee "${tmpdir}/irsa-sas.txt"

echo
echo "== Pods and their service accounts (cluster-wide) =="

# 2. List all pods and their SAs, marking whether the SA has IRSA
{
  printf "NAMESPACE\tPOD\tSERVICE_ACCOUNT\tHAS_IRSA_SA_ANNOTATION\n"
  for ns in "${NS_LIST[@]}"; do
    kubectl get pods -n "${ns}" -o json \
    | jq -r --arg ns "${ns}" '
        .items[]
        | [
            .metadata.namespace,
            .metadata.name,
            (.spec.serviceAccountName // "default"),
            (if .spec.serviceAccountName == null then "UNKNOWN"
             else "CHECK"
             end)
          ]
          | @tsv
      ' || true
  done
} | while IFS=$'\t' read -r ns pod sa flag; do
  if [[ "${ns}" == "NAMESPACE" ]]; then
    echo -e "${ns}\t${pod}\t${sa}\t${flag}"
    continue
  fi
  # Determine if SA has IRSA annotation
  if kubectl get sa "${sa}" -n "${ns}" -o json 2>/dev/null \
     | jq -e '.metadata.annotations["eks.amazonaws.com/role-arn"]' >/dev/null; then
    has_irsa="yes"
  else
    has_irsa="no"
  fi
  echo -e "${ns}\t${pod}\t${sa}\t${has_irsa}"
done | tee "${tmpdir}/pods-sa-irsa.txt"

echo
echo "== Summary: pods whose service accounts DO NOT have an IRSA role (potentially using node IAM role) =="

awk 'NR==1 {print; next} $4=="no" {print}' "${tmpdir}/pods-sa-irsa.txt" \
  | tee "${tmpdir}/pods-missing-irsa.txt"

echo
echo "== Optional: Check if node IAM role has broad permissions (coarse indicator) =="

# 3. Identify node IAM role(s) used by the EKS worker nodes (if using EKS-managed or self-managed nodes with IAM roles)
#    This section is informational; you may need to adapt for your environment.

# Try to derive the cluster name from current context
CURRENT_CONTEXT="$(kubectl config current-context 2>/dev/null || true)"
CLUSTER_NAME=""
if [[ -n "${CURRENT_CONTEXT}" ]]; then
  # Common eks context pattern: arn:aws:eks:region:account:cluster/CLUSTER_NAME
  CLUSTER_NAME="$(aws eks list-clusters --output json 2>/dev/null \
    | jq -r --arg ctx "${CURRENT_CONTEXT##*/}" '
        .clusters[]
        | select(. == $ctx)
      ' || true)"
fi

if [[ -z "${CLUSTER_NAME}" ]]; then
  echo "Could not reliably determine EKS cluster name from kubectl context; skipping node IAM role analysis." >&2
else
  echo "Using EKS cluster: ${CLUSTER_NAME}" >&2

  # Describe nodegroups and pull node IAM roles (for managed nodegroups)
  echo "Managed nodegroup IAM roles (if any):" >&2
  aws eks list-nodegroups --cluster-name "${CLUSTER_NAME}" --output json \
  | jq -r '.nodegroups[]' \
  | while read -r ng; do
      aws eks describe-nodegroup --cluster-name "${CLUSTER_NAME}" --nodegroup-name "${ng}" --output json \
      | jq -r --arg ng "${ng}" '
          .nodegroup.nodeRole
          | "nodegroup \($ng) IAM role: \(. )"
        '
    done 2>/dev/null || true
fi

cat <<'EOF'

INTERPRETING THE OUTPUT:

1) The "ServiceAccounts with IRSA annotation" section lists all Kubernetes service
   accounts that already have an IAM role associated via the
   eks.amazonaws.com/role-arn annotation. Pods using these SAs are using IRSA.

2) The "Pods and their service accounts (cluster-wide)" and "Summary" sections:
   - Any pod with HAS_IRSA_SA_ANNOTATION = "no" is a candidate for review.
   - These pods are likely falling back to the node IAM role to access AWS APIs.

3) A finding (POTENTIAL PROBLEM) is indicated when:
   - A workload requires AWS API access AND
   - Its service account does not have eks.amazonaws.com/role-arn set (HAS_IRSA_SA_ANNOTATION = "no"), AND
   - The node IAM role attached to the worker nodes has broad permissions that are
     not least-privilege relative to that workload.

NEXT STEPS (MANUAL REVIEW, NOT AUTOMATED FIX):

- For each pod listed in "pods-missing-irsa.txt":
  * Determine whether the application inside actually calls AWS APIs
    (review code, images, environment variables, configuration).
  * If it does, plan to:
      - Create a dedicated Kubernetes service account for that workload.
      - Create an IAM role with least-privilege permissions.
      - Annotate the service account with eks.amazonaws.com/role-arn.
      - Update the workload spec to use that service account.
  * If it does not use AWS at all, no change is required for this control.

EOF