Hardening AWS EKS IRSA: Blue Team OIDC & Pod Identity Guide

Overview & Defensive Context: The Perils of Ambient Cloud Identity#

Harden AWS EKS IRSA against token theft: pin OIDC trust conditions, migrate to EKS Pod Identity, enforce IMDSv2, and deploy CloudTrail alarms.

In our morning threat architecture analysis, we deconstructed the offensive mechanics of Amazon EKS IAM Roles for Service Accounts (IRSA) privilege escalation (mapped to MITRE ATT&CK T1078.004: Valid Accounts: Cloud Accounts, T1558: Steal or Forge Web Identity Tokens, and T1552.005: Unsecured Credentials: Cloud Instance Metadata / Projected Tokens). We demonstrated how Kubernetes Projected Service Account Tokens (PSAT)—mounted into containers at /var/run/secrets/eks.amazonaws.com/serviceaccount/token—can be extracted via pod remote code execution or local file inclusion. When enterprise IAM roles are provisioned with overly permissive wildcard trust relationships (such as StringLike: "system:serviceaccount:*:*"), AWS Security Token Service (sts:AssumeRoleWithWebIdentity) unconditionally honors token exchange requests from any pod in any namespace. This allows an attacker who breaches an unprivileged, public-facing container in a staging or guest namespace to assume administrative cloud credentials (AdministratorAccess) and execute full AWS account takeover.

For cloud security architects, Kubernetes platform engineers, and blue teams, defending containerized workloads against cloud identity compromise exposes fundamental structural flaws in multi-tenant cloud-native architectures:

The Fallacy of Kubernetes Namespace Boundaries: Kubernetes namespaces provide resource isolation, network policy scoping, and RBAC logical partitioning within the container cluster. However, the AWS Cloud Control Plane and IAM policy evaluation engine have no native visibility into Kubernetes internal namespaces. IAM relies entirely on the claims embedded within the OIDC JSON Web Token (JWT). If an IAM trust policy uses wildcards (*) when matching the token's subject (sub), the Kubernetes namespace boundary completely dissolves at the cloud boundary.
The Vulnerability of Reusable OIDC Federation Tokens: By design, Projected Service Account Tokens are valid for up to 24 hours (with standard 1-hour renewal cycles) and are signed by the cluster's public OIDC provider. Because AWS STS is a globally accessible, public API endpoint (https://sts.amazonaws.com/), an attacker who exfiltrates a projected token can call AssumeRoleWithWebIdentity from any external machine or C2 server on the internet, completely bypassing internal VPC routing and firewall controls unless explicit IP-based condition keys are declared.
The Architectural Shift to EKS Pod Identity: Recognizing the operational complexity and security pitfalls of managing complex OIDC trust policy strings, AWS introduced EKS Pod Identity in late 2023. Pod Identity replaces public OIDC discovery endpoints and projected token files with an in-cluster agent daemonset that authenticates directly via the EKS control plane. Credentials are tied directly to cluster, namespace, and service account attributes via Attribute-Based Access Control (ABAC) session tags, eliminating the exposure of token files and public OIDC endpoints.
The Blueprint for Enterprise Workload Identity Hardening: Securing EKS container identities requires implementing multi-layered controls across five distinct tiers: enforcing exact StringEquals matching on all IAM role trust relationships, migrating legacy IRSA workloads to EKS Pod Identity, restricting EC2 Instance Metadata Service (IMDSv2) hop limits to block node-level credential theft, deploying Kubernetes admission policies (Kyverno / OPA Gatekeeper) to prevent unauthorized role annotations, and monitoring AWS CloudTrail for anomalous web identity role assumptions.

Warning

Using StringLike with wildcards in the sub claim of an IAM trust policy permits any container in your EKS cluster to assume that role. Trust policies must strictly pin the exact namespace and service account using StringEquals.

⚔️ Exploitation Mechanics: For root-cause memory corruption analysis and attack flow, see our deep-dive: Deconstructing Breakdown.

Architecture Hardening: Five-Tier Defense-in-Depth for Workload Identity#

Securing AWS EKS workloads against token theft, wildcard trust exploitation, and unauthorized cloud privilege escalation requires deploying architectural controls across IAM trust policies, cluster identity mechanisms, node metadata, Kubernetes admission webhooks, and SIEM telemetry.

Defense Architecture Flowchart#

flowchart TD
    classDef client fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef gate fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef secure fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef audit fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef pass fill:#065f46,stroke:#34d399,stroke-width:2px,color:#a7f3d0

    Attacker[Adversary Breaches Container & Attempts Cloud Escalation]:::client --> VectorCheck{Attack Vector Selection}:::gate

    VectorCheck -- Tries Querying EC2 IMDS at 169.254.169.254 --> IMDSGate{Tier 1: EC2 Node IMDSv2 Hop Limit Gate}:::gate
    IMDSGate -- Hop Limit = 2 or IMDSv1 Active --> StolenNodeRole[Action: Attacker Steals EC2 Worker Node IAM Role]:::drop
    IMDSGate -- Hop Limit = 1 & IMDSv2 Enforced --> BlockIMDS[Action: Packet Dropped by Kernel at Container Bridge]:::secure

    VectorCheck -- Extracts Projected Token & Calls AssumeRoleWithWebIdentity --> TrustGate{Tier 2: IAM Role Trust Relationship Evaluation}:::gate

    TrustGate -- Trust Uses Wildcard StringLike system:serviceaccount:*:* --> PermissiveMatch[Condition Matches: Full Administrative Role Issued]:::drop
    PermissiveMatch --> CloudCompromise[Adversary Compromises AWS Account via Stolen Role]:::drop

    TrustGate -- Trust Uses StringEquals Pinned to Namespace & SA --> ExactMatchCheck{Does Token Namespace & SA Match Policy?}:::gate
    ExactMatchCheck -- Unprivileged Pod in Default / Staging Namespace --> STSReject[Action: AWS STS Returns AccessDenied]:::pass
    ExactMatchCheck -- Legitimate Production Backend Pod --> STSIssue[Action: Scoped Temporary Credentials Issued]:::secure

    Attacker -- Attempts Adding eks.amazonaws.com/role-arn Annotation --> AdmissionGate{Tier 3: Kubernetes Admission Controller Policy}:::gate
    AdmissionGate -- Kyverno / Gatekeeper Rule Blocks Unauthorized Annotation --> DropKubeApply[Action: Admission Webhook Rejects Pod Deployment]:::pass

    STSIssue --> CloudTrailGate{Tier 4: CloudTrail & GuardDuty Telemetry}:::gate
    CloudTrailGate -- AssumeRoleWithWebIdentity from External Public IP --> AlertSIEM[Action: High-Severity SOC Alert & Automated Role Quarantine]:::audit

    VectorCheck -- Modern Architecture: EKS Pod Identity Active --> PodIdentGate{Tier 5: EKS Pod Identity & ABAC Enforcement}:::gate
    PodIdentGate -- In-Cluster Agent Authenticates Request with Cluster Context --> ABACValidate[Action: Temporary Credentials Vended with Session Tags]:::secure

Tier 1: OIDC Trust Policy Hardening & Exact Subject Pinning#

The primary structural remediation for CVE-2024-style IRSA misconfigurations is eliminating all wildcard StringLike condition keys in IAM role trust relationships. Trust relationships must strictly enforce StringEquals matching both the exact Kubernetes namespace and the exact service account name.

Hardened IAM Trust Relationship Policy (`trust-policy-hardened.json`)

Deploy the following hardened trust relationship on all IAM roles intended for EKS workloads:

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceExactServiceAccountBinding",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::112233445566:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/D89B5F7A2C1E4A3B9C8E7D6F5A4B3C2D"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/D89B5F7A2C1E4A3B9C8E7D6F5A4B3C2D:aud": "sts.amazonaws.com",
          "oidc.eks.us-east-1.amazonaws.com/id/D89B5F7A2C1E4A3B9C8E7D6F5A4B3C2D:sub": "system:serviceaccount:production:payment-processor-sa"
        }
      }
    }
  ]
}

Automated Bash Script: Auditing IAM Roles for Wildcard IRSA Policies

Run this audit script across your AWS accounts to discover any IAM roles containing dangerous wildcard trust policies:

BASH

#!/usr/bin/env bash
# audit_irsa_wildcards.sh - Scan AWS IAM roles for wildcard OIDC trust conditions
set -euo pipefail

echo "[*] Auditing IAM roles for overly permissive EKS OIDC trust policies..."

ROLES=$(aws iam list-roles --query "Roles[?AssumeRolePolicyDocument.Statement[?Action=='sts:AssumeRoleWithWebIdentity']].RoleName" --output text)

VULN_COUNT=0

for ROLE in $ROLES; do
    POLICY=$(aws iam get-role --role-name "$ROLE" --query "Role.AssumeRolePolicyDocument" --output json)
    
    # Check if policy contains StringLike and wildcards in the sub condition
    if echo "$POLICY" | grep -q 'system:serviceaccount:.*\*'; then
        echo -e "\033[0;31m[CRITICAL] Role '$ROLE' contains wildcard service account trust condition!\033[0m"
        echo "$POLICY" | jq .Statement[].Condition
        VULN_COUNT=$((VULN_COUNT + 1))
    fi
done

if [ "$VULN_COUNT" -eq 0 ]; then
    echo -e "\033[0;32m[OK] No wildcard IRSA trust policies identified across evaluated roles.\033[0m"
else
    echo -e "\033[0;31m[!] Identified $VULN_COUNT vulnerable IAM roles requiring immediate remediation.\033[0m"
    exit 2
fi

Tier 2: Migrating to Amazon EKS Pod Identity#

For clusters running EKS 1.24 or higher, migrating from IRSA to EKS Pod Identity completely eliminates OIDC federation token files and public OIDC provider discovery risks.

How EKS Pod Identity Solves IRSA Vulnerabilities

No Projected Token Files on Disk: Pod Identity does not mount long-lived JWTs to /var/run/secrets/eks.amazonaws.com/serviceaccount/token. Instead, the EKS Pod Identity Agent (a daemonset running on worker nodes) intercepts credential requests and vends temporary credentials directly.
Simplified, Centralized Trust Policy: Instead of unique OIDC provider ARNs per cluster, all Pod Identity roles trust a single principal: pods.eks.aws.
Attribute-Based Access Control (ABAC): AWS automatically tags temporary credentials with session tags (aws:PrincipalTag/eks-cluster-arn, aws:PrincipalTag/kubernetes-namespace, aws:PrincipalTag/kubernetes-service-account), allowing fine-grained authorization policies without manual trust policy edits.

EKS Pod Identity Trust Relationship

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.aws"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

Creating the Association via AWS CLI:

BASH

# Associate the IAM role directly with the EKS cluster, namespace, and service account
aws eks create-pod-identity-association \
  --cluster-name production-cluster \
  --namespace production \
  --service-account payment-processor-sa \
  --role-arn arn:aws:iam::112233445566:role/PaymentProcessorRole

Tier 3: Restricting Node-Level IMDSv2 Access from Pods#

If an attacker cannot assume an IRSA role, they frequently fall back to querying the EC2 Instance Metadata Service (IMDS) at 169.254.169.254 to steal the worker node's IAM instance profile credentials.

1. Enforce IMDSv2 and Set Hop Limit to 1 on Worker Nodes

By configuring http-put-response-hop-limit to 1, the IP packet's Time-To-Live (TTL) expires at the virtual ethernet container bridge (cni0 or docker0), preventing any container from receiving responses from the metadata service:

BASH

# Enforce IMDSv2 and block container access by setting hop limit to 1
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1 \
  --http-endpoint enabled

2. Host-Level iptables Rule on Worker Nodes

Ensure host network firewalls drop traffic targeting the metadata service from non-host network namespaces:

BASH

# Drop outbound traffic to IMDS from container network interfaces
iptables -A FORWARD -d 169.254.169.254/32 -j DROP

Tier 4: Kubernetes Admission Controls via Kyverno#

Deploy a Kyverno admission controller policy to prevent developers or compromised service accounts from annotating unauthorized service accounts with high-privilege IAM roles (eks.amazonaws.com/role-arn):

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-eks-role-arn-annotation
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: block-unauthorized-iam-roles
      match:
        any:
          - resources:
              kinds:
                - ServiceAccount
      validate:
        message: "Binding high-privilege IAM roles to service accounts is strictly restricted."
        pattern:
          metadata:
            =(annotations):
              =(eks.amazonaws.com/role-arn): "!*Admin* & !*FullAccess*"

Production Detection Queries: Hunting Anomalous STS Invocations#

Blue teams must deploy continuous detection monitoring across AWS CloudTrail and Amazon GuardDuty to detect unauthorized token exchanges and external STS invocations.

Production Sigma Detection Rule: Unusual AssumeRoleWithWebIdentity Invocation#

The following production-ready Sigma rule monitors AWS CloudTrail events to identify instances where AssumeRoleWithWebIdentity is invoked from external public IP addresses (outside the corporate NAT / VPC range) or uses service accounts from unauthorized namespaces:

YAML

title: Suspicious AWS STS AssumeRoleWithWebIdentity Invocations (IRSA Token Abuse)
id: 4e8b2c1f-9a7d-4c3e-8f12-b5e8a7d1c3f4
status: production
description: |
    Detects instances where AWS STS AssumeRoleWithWebIdentity is invoked from an IP address outside
    known enterprise EKS VPC NAT gateways, or requests high-privilege administrative IAM roles,
    indicative of exfiltrated Projected Service Account Tokens (PSAT) or wildcard trust abuse.
references:
    - https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
    - https://attack.mitre.org/techniques/T1078/004/

tags:
    - attack.credential_access
    - attack.t1078.004
    - attack.privilege_escalation
    - attack.t1068
logsource:
    service: cloudtrail
    product: aws
detection:
    selection_event:
        eventName: 'AssumeRoleWithWebIdentity'
        eventSource: 'sts.amazonaws.com'
    selection_privilege:
        requestParameters.roleArn|contains:
            - 'Admin'
            - 'Administrator'
            - 'FullAccess'
            - 'Organization'
    filter_trusted_vpc_nat:
        sourceIPAddress|startswith:
            - '10.'
            - '172.16.'
            - '192.168.'
            # Replace with your company's authorized EKS Egress NAT Elastic IPs:
            - '198.51.100.'
    condition: selection_event and selection_privilege and not filter_trusted_vpc_nat
falsepositives:
    - External multi-cloud federated workloads explicitly authorized to assume roles from third-party IP blocks.
level: critical

Amazon CloudWatch Log Insights Query: Auditing IRSA Token Usage#

Query CloudTrail events in CloudWatch Logs Insights to audit which Kubernetes service accounts are assuming IAM roles:

PLAINTEXT

fields @timestamp, requestParameters.roleArn, responseElements.assumedRoleUser.arn, sourceIPAddress, userAgent
| filter eventName = "AssumeRoleWithWebIdentity"
| parse requestParameters.roleArn "role/*" as assumedRole
| stats count(*) as Invocations by requestParameters.roleArn, sourceIPAddress
| sort Invocations desc
| limit 100

Enterprise Mitigation Matrix: Comparing Remediations for EKS Workload Identity#

The following matrix compares available defensive controls across security effectiveness, implementation complexity, operational risk, and enterprise trade-offs:

Defensive Approach	Control Tier	Primary Mechanism	Implementation Complexity	Performance Impact	Operational Risk	Overall Effectiveness
Pin Trust Policy to Exact SA (`StringEquals`)	IAM Policy	Replaces `StringLike` wildcards with explicit namespace and account	Low (Direct JSON policy update)	Zero (0%)	Very Low (Ensures only designated pod assumes role)	Definitive for IRSA
Migrate to EKS Pod Identity	Identity Architecture	In-cluster agent daemonset vends credentials using ABAC session tags	Medium (Requires EKS 1.24+ and addon installation)	Zero (0%)	Low (Eliminates OIDC discovery endpoints and token files)	Architectural (Next-Gen)
IMDSv2 Hop Limit = 1	Node Security	Drops packets to metadata service originating from container bridges	Low (One-line AWS CLI command)	Zero (0%)	Low (Pods requiring IMDS must be migrated to IRSA)	High (Blocks Node Theft)
Kyverno Admission Annotation Guard	Kubernetes Policy	Rejects pod/SA specs with unauthorized `eks.amazonaws.com/role-arn`	Medium (Requires Kyverno / OPA Gatekeeper engine)	Minimal (<10ms webhook latency)	Low to Medium (May reject non-compliant developer deployments)	High (Prevents Rogue Binds)
IAM Permission Boundaries on Roles	IAM Governance	Sets maximum permission ceiling on roles regardless of policies	Medium (Requires organization-wide IAM policy templates)	Zero (0%)	Low (Prevents accidental privilege expansion)	High (Blast Radius Cap)
CloudTrail External IP Alerting	Detection Telemetry	Detects `AssumeRoleWithWebIdentity` calls from outside cluster NAT	Low (SIEM / CloudWatch alert configuration)	Zero (0%)	Zero (Read-only monitoring)	High (Rapid Detection)

Incident Response & Verification Playbook: Blue Team Containment & Auditing#

When a SIEM alert or CloudTrail audit reveals suspicious AssumeRoleWithWebIdentity invocations or potential projected token leakage, execute the following incident response workflow:

Incident Response Flowchart#

flowchart TD
    classDef client fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef gate fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef secure fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef audit fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5

    Alert[SIEM Alert: AssumeRoleWithWebIdentity from External IP / Unusual Namespace]:::client --> Triage{Phase 1: Alert Triage & Scope Analysis}:::gate

    Triage -- Known CI/CD Runner with Valid Change Ticket --> ValidateBenign[Verify Pipeline Run & Close Alert]:::secure
    Triage -- Unknown Public IP / Compromised Pod Namespace --> Incident[Confirmed Token Theft / Wildcard Abuse]:::drop

    Incident --> Containment{Phase 2: Immediate IAM & Cluster Containment}:::gate
    Containment --> RevokeSessions[Attach Deny Policy to IAM Role: Invalidate All Active Sessions]:::drop
    Containment --> LockTrustPolicy[Update Trust Policy: Remove Federated Principal or Set Explicit Sub]:::drop
    Containment --> TerminatePod[Delete Compromised Kubernetes Pod via kubectl delete pod]:::drop

    Containment --> Forensics{Phase 3: Digital Forensics & CloudTrail Auditing}:::gate
    Forensics --> QueryCloudTrail[Query CloudTrail for All API Actions Undertaken by Assumed Role]:::audit
    Forensics --> InspectPodLogs[Extract Container Memory & Pod Logs to Identify RCE Vector]:::audit
    Forensics --> ScanClusterRoles[Run audit_irsa_wildcards.sh to Identify Other Exposed Roles]:::audit

    Forensics --> Remediation{Phase 4: Eradication & Hardening}:::gate
    Remediation --> DeployPodIdentity[Migrate Impacted Workload to EKS Pod Identity]:::secure
    Remediation --> EnforceKyverno[Deploy Kyverno ClusterPolicy to Block Unauthorized Annotations]:::secure
    Remediation --> LockIMDS[Verify IMDSv2 Hop Limit = 1 Across All Worker Nodes]:::secure

Step-by-Step Response Checklist#

Phase 1: Token Compromise Scoping & CloudTrail Auditing

Identify the assumed IAM role ARN and session name (responseElements.assumedRoleUser.arn) from the CloudTrail alert.
Extract the sourceIPAddress and userAgent associated with the AssumeRoleWithWebIdentity call.
Decode the requestParameters.webIdentityToken (if logged or available) to inspect the issuing cluster OIDC URL, namespace, and service account subject.
Query CloudTrail for all subsequent management and data events executed by the assumed role session within the past 24 hours.

Phase 2: IAM Role Quarantine & Session Invalidation

Immediately invalidate all active temporary sessions for the compromised IAM role by attaching an inline revocation policy:

JSON

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "DateLessThan": {
            "aws:TokenIssueTime": "2026-10-27T15:45:00Z"
          }
        }
      }
    ]
  }

Edit the role's AssumeRolePolicyDocument to immediately remove the federated OIDC provider or replace the wildcard sub condition with a non-existent dummy subject (system:serviceaccount:quarantine:blocked).

Phase 3: Cluster Pod & Admission Policy Sanitization

Locate and isolate the compromised Kubernetes pod associated with the service account using kubectl get pods --all-namespaces -o wide.
Capture pod memory and container logs for forensic analysis before executing kubectl delete pod <pod-name> -n <namespace>.
Run audit_irsa_wildcards.sh across all AWS accounts in the AWS Organization to identify and patch all remaining wildcard trust policies.
Deploy Kyverno / Gatekeeper policies to enforce exact role binding validation and verify IMDSv2 hop limits (hop-limit: 1) on all worker node launch templates.

Executive Takeaway Table: Threat Vectors, Detection Signals, and Primary Mitigations#

The following executive summary consolidates the core attack vectors, defensive telemetry signals, and recommended engineering remediations for AWS EKS IRSA architectures:

Attack Vector / Technique	Primary Exploitation Mechanism	Telemetry & Detection Signal	Recommended Mitigation	Verification Command
Wildcard OIDC Trust (T1068)	`StringLike: system:serviceaccount::` allows any pod in cluster to assume role	CloudTrail: `AssumeRoleWithWebIdentity` from untrusted pod namespaces	Enforce `StringEquals` matching exact namespace & service account	Run `audit_irsa_wildcards.sh`
External Token Replay	Stolen projected token used outside the AWS VPC via public STS endpoint	CloudTrail: `AssumeRoleWithWebIdentity` source IP is outside cluster NAT	Restrict IAM trust with `aws:SourceIp` or migrate to EKS Pod Identity	Audit CloudTrail `sourceIPAddress`
Node Metadata Theft (T1552)	Pod queries IMDS at `169.254.169.254` to harvest worker node IAM role	CloudTrail: Sudden spike in API calls from EC2 worker node instance role	Set `http-put-response-hop-limit: 1` and enforce IMDSv2 across nodes	`aws ec2 describe-instances --query '...MetadataOptions'`
Rogue Role Annotation	Unauthorized user annotates ServiceAccount with high-privilege role ARN	Kubernetes Audit Log: `UPDATE` / `CREATE` on ServiceAccount metadata	Enforce Kyverno / Gatekeeper policy blocking unauthorized role ARNs	`kubectl get serviceaccounts -A -o yaml`
Cross-Cluster Token Reuse	Shared OIDC issuer URL allows dev cluster tokens to assume prod roles	CloudTrail: Role assumed from unintended cluster OIDC provider ARN	Provision distinct OIDC identity providers per cluster; pin issuer	`aws iam list-open-id-connect-providers`

Authoritative References & Standards#

Amazon Web Services Documentation: IAM Roles for Service Accounts (IRSA) Technical Specification — AWS EKS Documentation
Amazon Web Services Documentation: EKS Pod Identity Overview & Migration Guidance — AWS EKS Pod Identity Docs
Kubernetes Official Documentation: Service Account Token Volume Projection Architecture — Kubernetes Documentation
MITRE ATT&CK Framework: Technique T1078.004: Valid Accounts: Cloud Accounts — MITRE ATT&CK

Hardening AWS EKS IRSA: Blue Team OIDC & Pod Identity Guide

Overview & Defensive Context: The Perils of Ambient Cloud Identity#

Architecture Hardening: Five-Tier Defense-in-Depth for Workload Identity#

Defense Architecture Flowchart#

Tier 1: OIDC Trust Policy Hardening & Exact Subject Pinning#

Hardened IAM Trust Relationship Policy (`trust-policy-hardened.json`)

Automated Bash Script: Auditing IAM Roles for Wildcard IRSA Policies

Tier 2: Migrating to Amazon EKS Pod Identity#

How EKS Pod Identity Solves IRSA Vulnerabilities

EKS Pod Identity Trust Relationship

Creating the Association via AWS CLI:

Tier 3: Restricting Node-Level IMDSv2 Access from Pods#

1. Enforce IMDSv2 and Set Hop Limit to 1 on Worker Nodes

2. Host-Level iptables Rule on Worker Nodes

Tier 4: Kubernetes Admission Controls via Kyverno#

Production Detection Queries: Hunting Anomalous STS Invocations#

Production Sigma Detection Rule: Unusual AssumeRoleWithWebIdentity Invocation#

Amazon CloudWatch Log Insights Query: Auditing IRSA Token Usage#

Enterprise Mitigation Matrix: Comparing Remediations for EKS Workload Identity#

Incident Response & Verification Playbook: Blue Team Containment & Auditing#

Incident Response Flowchart#

Step-by-Step Response Checklist#

Phase 1: Token Compromise Scoping & CloudTrail Auditing

Phase 2: IAM Role Quarantine & Session Invalidation

Phase 3: Cluster Pod & Admission Policy Sanitization

Executive Takeaway Table: Threat Vectors, Detection Signals, and Primary Mitigations#

Authoritative References & Standards#

Comments

Post a Comment

Hardening AWS EKS IRSA: Blue Team OIDC & Pod Identity Guide

Overview & Defensive Context: The Perils of Ambient Cloud Identity#

Architecture Hardening: Five-Tier Defense-in-Depth for Workload Identity#

Defense Architecture Flowchart#

Tier 1: OIDC Trust Policy Hardening & Exact Subject Pinning#

Hardened IAM Trust Relationship Policy (trust-policy-hardened.json)

Automated Bash Script: Auditing IAM Roles for Wildcard IRSA Policies

Tier 2: Migrating to Amazon EKS Pod Identity#

How EKS Pod Identity Solves IRSA Vulnerabilities

EKS Pod Identity Trust Relationship

Creating the Association via AWS CLI:

Tier 3: Restricting Node-Level IMDSv2 Access from Pods#

1. Enforce IMDSv2 and Set Hop Limit to 1 on Worker Nodes

2. Host-Level iptables Rule on Worker Nodes

Tier 4: Kubernetes Admission Controls via Kyverno#

Production Detection Queries: Hunting Anomalous STS Invocations#

Production Sigma Detection Rule: Unusual AssumeRoleWithWebIdentity Invocation#

Amazon CloudWatch Log Insights Query: Auditing IRSA Token Usage#

Enterprise Mitigation Matrix: Comparing Remediations for EKS Workload Identity#

Incident Response & Verification Playbook: Blue Team Containment & Auditing#

Incident Response Flowchart#

Step-by-Step Response Checklist#

Phase 1: Token Compromise Scoping & CloudTrail Auditing

Phase 2: IAM Role Quarantine & Session Invalidation

Phase 3: Cluster Pod & Admission Policy Sanitization

Executive Takeaway Table: Threat Vectors, Detection Signals, and Primary Mitigations#

Authoritative References & Standards#

Comments

Post a Comment

Hardened IAM Trust Relationship Policy (`trust-policy-hardened.json`)