Practical Zero-Trust Security in Amazon EKS Using IRSA, Security Groups for Pods, and Network Policies

Modern Kubernetes platforms are powerful, but many Amazon EKS environments still operate with overly broad trust boundaries. In large-scale production systems, this becomes a major security concern.

In this article, we’ll walk through a practical zero-trust architecture for Amazon EKS using:

• IAM Roles for Service Accounts (IRSA)
• Security Groups for Pods (SGP)
• Kubernetes Network Policies

Together, these technologies help reduce blast radius, prevent lateral movement, and improve workload isolation.

Why Traditional EKS Security Fails

Historically, many Kubernetes workloads inherited permissions directly from EC2 node IAM roles.

EC2 Node IAM Role → Shared Across All Pods

This creates several risks:

• Excessive AWS permissions
• Credential exposure
• Lateral movement between workloads
• Weak tenant isolation

Every workload should only access the exact resources it requires.

Layer 1 — IAM Roles for Service Accounts (IRSA)

What IRSA Solves

IRSA allows Kubernetes service accounts to assume dedicated IAM roles. Instead of sharing node-level credentials, each workload receives isolated temporary AWS credentials.

IRSA Authentication Flow

Pod
  ↓
Service Account
  ↓
OIDC Token
  ↓
AWS STS AssumeRoleWithWebIdentity
  ↓
Temporary IAM Credentials

Example IAM Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::payments-data/*"
      ]
    }
  ]
}

Kubernetes Service Account Example

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payments-api
  namespace: payments
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/payments-irsa-role

Once configured, the pod receives temporary AWS credentials scoped only to the required permissions.

Layer 2 — Security Groups for Pods (SGP)

IRSA secures identity. Security Groups for Pods secure network access.

Normally, pods inherit the EC2 node security group. SGP allows dedicated security groups to be attached directly to pods.

Benefits of SGP

• Pod-level firewalling
• Granular ingress and egress control
• Reduced east-west exposure
• AWS-native workload isolation

Example SecurityGroupPolicy

apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: payments-sg-policy
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  securityGroups:
    groupIds:
      - sg-0123456789abcdef0

This attaches a dedicated security group directly to matching pods.

Layer 3 — Kubernetes Network Policies

By default, Kubernetes allows unrestricted pod-to-pod communication.

All pods can communicate with all other pods.

Network Policies introduce explicit traffic controls.

Default Deny Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

This blocks all ingress and egress traffic until explicitly allowed.

Allow Frontend Namespace Access

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api

  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend

    ports:
    - protocol: TCP
      port: 8080

Only workloads from the frontend namespace can now access the payments API.

Combining IRSA, SGP, and Network Policies

Layer	Purpose
IRSA	AWS identity isolation
SGP	VPC-level workload firewalling
Network Policies	Kubernetes east-west traffic control
RBAC	Kubernetes API authorization

Together, these layers create a practical zero-trust model for Amazon EKS.

Production Recommendations

• Use IRSA for every application workload
• Start with deny-by-default networking
• Use Security Groups for Pods selectively
• Automate enforcement using Terraform and GitOps
• Continuously monitor IAM and network activity

Final Thoughts

Kubernetes security is not a single feature. It is a layered engineering discipline.

IRSA, Security Groups for Pods, and Kubernetes Network Policies each solve different parts of the security problem:

• Identity isolation
• Network segmentation
• Workload-level security boundaries

Used together, they significantly improve the security posture of Amazon EKS platforms operating at scale.