Manage Kubernetes Rbac Users With Aws Iam Authenticator For Kubernetes

More Info:

Amazon EKS uses IAM to provide authentication to your Kubernetes cluster through the AWS IAM Authenticator for Kubernetes. You can configure the stock kubectl client to work with Amazon EKS by installing the AWS IAM Authenticator for Kubernetes and modifying your kubectl configuration file to use it for authentication.

Risk Level

Low

Address

Security

Compliance Standards

• APRA CPS 234 (Australia)
• BSI C5 (Germany)
• Brazil LGPD
• CCPA / CPRA (California)
• CIS Critical Security Controls v8
• CIS EKS
• CMMC 2.0
• CSA Cloud Controls Matrix v4
• DPDPA
• Digital Operational Resilience Act (EU)
• Essential 8
• ISO/IEC 27017
• ISO/IEC 27018
• ISO/IEC 27701
• KSA PDPL
• MAS Technology Risk Management (Singapore)
• MITRE ATT&CK (Cloud)
• NIS2 Directive
• NIST SP 800-171
• NYDFS 23 NYCRR 500
• SWIFT Customer Security Controls Framework
• Sarbanes-Oxley IT General Controls
• UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Remediation

Manual Steps

1. Inventory how users currently authenticate to the cluster

   • On any machine with kubectl access, show the current contexts and auth config:

     kubectl config view --minify --raw
     kubectl config get-contexts

   • Inspect the active user entry and note whether it uses exec with aws eks get-token, a static client certificate/key, a static bearer token, or another plugin.

2. Verify that IAM-based authentication is in use (preferred) or identify non‑IAM users

   • On any machine with kubectl access, check for aws-exec based authentication:

     kubectl config view --raw -o yaml | grep -A5 'user:' | grep -A5 'exec:'
     kubectl config view --raw -o jsonpath='{.users[*].user.exec.command}{"\n"}'

   • Confirm that the command is aws and the arguments include eks get-token and --cluster-name. Any users not using this pattern (e.g., client-certificate, token, or other plugins) should be flagged for review/migration.

3. Ensure your AWS CLI/tooling is aligned with EKS guidance

   • On any machine administering access, check AWS CLI version:

     aws --version

   • If it is older than 1.16.156, plan to either upgrade AWS CLI or use the legacy AWS IAM Authenticator following AWS docs. If it is 1.16.156 or newer, ensure users are configured to rely on aws eks get-token (not the separate authenticator binary).

4. Review and align aws-auth ConfigMap with intended IAM principals

   • On any machine with kubectl access, review current IAM-to-RBAC mappings:

     kubectl -n kube-system get configmap aws-auth -o yaml

   • Compare mapUsers, mapRoles, and mapAccounts entries against your organization’s IAM design (approved IAM roles/users, least privilege, use of roles instead of long‑lived users where possible). Note any principals that are no longer needed or that should be mapped to different Kubernetes groups.

5. Plan and apply corrections using EKS/IAM and ConfigMap updates

   • In AWS IAM / your IaC (CloudFormation/Terraform/CDK), ensure that:
     • Cluster access is granted via IAM roles (e.g., assumable roles for humans/CI), not long‑lived IAM users where feasible.
     • Policies attached to those roles are scoped to the EKS clusters they should access.
   • Update the EKS aws-auth ConfigMap via your chosen control-plane management method (console, CLI, or IaC) to:
     • Remove unused or unauthorized IAM users/roles.
     • Add the correct IAM roles/users and map them to appropriate Kubernetes groups (e.g., system:masters only for tightly controlled admin roles).
   • Do not attempt to edit this via kubectl if your process enforces IaC; change it in the source of truth instead.

6. Verify IAM Authenticator / AWS CLI integration and RBAC behavior

   • On any machine with kubectl access, regenerate kubeconfig using AWS CLI:

     aws eks update-kubeconfig --name <cluster-name> --region <region>
     kubectl config view --minify --raw

   • Confirm that authentication succeeds and that actions match expected RBAC permissions for each IAM role/user by testing representative operations (e.g., kubectl get pods, kubectl get nodes, kubectl auth can-i <verb> <resource>).

Using kubectl

kubectl cannot configure or manage Amazon EKS IAM authentication, so this finding cannot be fixed via Kubernetes API objects. The required changes must be made in the AWS/EKS control-plane configuration (AWS console, AWS CLI, or IaC); see the Manual Steps section for how to review and remediate.

Automation

#!/usr/bin/env bash
#
# Audit EKS IAM/RBAC usage and legacy aws-iam-authenticator dependencies
#
# Requirements:
# - Run on any machine with kubectl and aws CLI configured for the cluster
# - jq recommended for nicer output (optional)

set -euo pipefail

echo "== 1. Cluster access method (auth provider in kubeconfig) =="
KUBECONFIG_PATH="${KUBECONFIG:-$HOME/.kube/config}"
echo "Using kubeconfig: ${KUBECONFIG_PATH}"
echo

# Show auth-provider or exec-based auth config for current-context user
python3 - <<'PY' "${KUBECONFIG_PATH}" 2>/dev/null || ruby - <<'RB' "${KUBECONFIG_PATH}" 2>/dev/null || true
import sys, yaml, os
cfg_path = sys.argv[1]
with open(cfg_path) as f:
    cfg = yaml.safe_load(f)
ctx_name = cfg.get('current-context')
ctx = next((c for c in cfg.get('contexts', []) if c.get('name') == ctx_name), {})
user_name = ctx.get('context', {}).get('user')
user = next((u for u in cfg.get('users', []) if u.get('name') == user_name), {})
print("Current context:", ctx_name)
print("Current user:", user_name)
u = user.get('user', {})
print("\nAuth config for current user:")
if 'auth-provider' in u:
    print("  type: auth-provider")
    print("  name:", u['auth-provider'].get('name'))
    print("  config:", u['auth-provider'].get('config'))
elif 'exec' in u:
    print("  type: exec")
    print("  command:", u['exec'].get('command'))
    print("  args:", " ".join(u['exec'].get('args', [])))
else:
    print("  type: static (token/cert/basic) or unknown")
PY
RB_CODE='
require "yaml"
cfg_path = ARGV[0]
cfg = YAML.load_file(cfg_path)
ctx_name = cfg["current-context"]
ctx = (cfg["contexts"] || []).find { |c| c["name"] == ctx_name } || {}
user_name = ctx.fetch("context", {})["user"]
user = (cfg["users"] || []).find { |u| u["name"] == user_name } || {}
puts "Current context: #{ctx_name}"
puts "Current user: #{user_name}"
u = user["user"] || {}
puts "\nAuth config for current user:"
if u.key?("auth-provider")
  ap = u["auth-provider"]
  puts "  type: auth-provider"
  puts "  name: #{ap["name"]}"
  puts "  config: #{ap["config"]}"
elsif u.key?("exec")
  ex = u["exec"]
  puts "  type: exec"
  puts "  command: #{ex["command"]}"
  puts "  args: #{(ex["args"] || []).join(" ")}"
else
  puts "  type: static (token/cert/basic) or unknown"
end
'
RB

echo
echo "== Interpretation =="
echo "- PROBLEM if you see 'auth-provider' with name 'aws-iam-authenticator' (legacy binary)."
echo "- PROBLEM if you see static tokens/certs/basic auth not relying on AWS IAM (e.g. embedded token)."
echo "- ACCEPTABLE if using 'exec' with 'aws eks get-token' (AWS CLI v1.16.156+)."
echo

echo "== 2. Cluster-info ConfigMaps (aws-auth presence) =="
echo "Checking for aws-auth ConfigMap in kube-system..."
if kubectl -n kube-system get configmap aws-auth >/dev/null 2>&1; then
  echo "aws-auth ConfigMap FOUND (normal for EKS)"
  echo
  echo "aws-auth .data.mapUsers:"
  kubectl -n kube-system get configmap aws-auth -o jsonpath='{.data.mapUsers}' 2>/dev/null || echo "<none>"
  echo
  echo "aws-auth .data.mapRoles:"
  kubectl -n kube-system get configmap aws-auth -o jsonpath='{.data.mapRoles}' 2>/dev/null || echo "<none>"
  echo
  echo "aws-auth .data.mapAccounts:"
  kubectl -n kube-system get configmap aws-auth -o jsonpath='{.data.mapAccounts}' 2>/dev/null || echo "<none>"
else
  echo "aws-auth ConfigMap NOT found in kube-system (unexpected for standard EKS clusters)."
fi

echo
echo "== Interpretation =="
echo "- Review mapUsers/mapRoles/mapAccounts to confirm they reference valid IAM users/roles/accounts."
echo "- PROBLEM if you see non-IAM identities (e.g. static group names without IAM ARNs) or empty mappings"
echo "  while still granting access via non-IAM mechanisms."
echo

echo "== 3. RBAC subjects that are NOT bound via mapped IAM entities =="
echo "Listing all RoleBindings and ClusterRoleBindings..."
# This does not prove misuse, but highlights non-serviceaccount human-like subjects
kubectl get clusterrolebindings,rolebindings --all-namespaces -o json |
  jq -r '
    .items[]
    | {kind, metadata: {name, namespace}, subjects}
    | select(.subjects != null)
    | . as $b
    | $b.subjects[]
    | [.kind, .name, .namespace, $b.kind, $b.metadata.name, ($b.metadata.namespace // "-")]
    | @tsv' 2>/dev/null || true

echo
cat <<'EOF'
Interpretation:
- Review the table above (SubjectKind, SubjectName, SubjectNamespace, BindingKind, BindingName, BindingNamespace).
- FOCUS on:
  - SubjectKind=User with names that are not IAM ARNs or OIDC identities managed by IAM.
  - Broad ClusterRoleBindings (e.g. cluster-admin) attached to such users or to groups.
- PROBLEM indicators:
  - 'User' subjects that are local, static, or opaque (e.g. "admin", "test", "ci-user") rather than IAM ARNs.
  - Groups used for access control that are not mapped from IAM via aws-auth or IRSA/OIDC.
EOF

echo
echo "== 4. Verify AWS CLI version and eks helpers on this machine =="
aws --version || echo "aws CLI not found"
echo
echo "Check for eks-related exec usage in kubeconfig (grep):"
grep -R --no-color -n "aws eks get-token" "${KUBECONFIG_PATH}" 2>/dev/null || echo "No explicit aws eks get-token exec found in kubeconfig"
echo
cat <<'EOF'
Interpretation:
- PROBLEM if you rely on the legacy 'aws-iam-authenticator' binary (seen in kubeconfig or PATH) instead of:
    aws eks get-token
- ACCEPTABLE if kubeconfig uses 'exec' with 'aws eks get-token' and this machine has AWS CLI >= 1.16.156.
EOF

What output indicates a problem

• kubeconfig shows:
  • auth-provider name aws-iam-authenticator, or
  • static tokens/certs/basic auth instead of exec using aws eks get-token.
• aws-auth ConfigMap:
  • missing on a standard EKS cluster, or
  • contains invalid/unused/legacy non-IAM identities.
• RBAC bindings:
  • User subjects that are not IAM ARNs or OIDC identities mapped from IAM.
  • Broad ClusterRoleBindings (e.g. cluster-admin) granted to such users or unmanaged groups.
• Local machine:
  • No evidence of aws eks get-token usage while cluster access is still configured via legacy aws-iam-authenticator.

Additional Reading:

• https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html