Lesson 08 — Amazon EKS Offensive Security

Learning Objectives

By the end of this lesson, you will be able to:

Understand Amazon EKS architecture.
Identify Kubernetes attack surfaces.
Enumerate Amazon EKS clusters.
Assess Kubernetes RBAC.
Review Service Accounts and IAM Roles for Service Accounts (IRSA).
Identify Kubernetes privilege escalation opportunities.
Understand Kubernetes attack paths.
Perform enterprise Amazon EKS security assessments.

Introduction

Containers and Kubernetes have become the preferred platform for deploying modern cloud applications.

Amazon Elastic Kubernetes Service (Amazon EKS) allows organizations to run managed Kubernetes clusters while AWS manages the Kubernetes control plane.

Although AWS secures the control plane, customers remain responsible for securing:

Worker Nodes
Pods
Containers
RBAC
Service Accounts
Network Policies
Secrets
Applications
IAM Integration

Because Kubernetes environments often host mission-critical applications, Amazon EKS is a high-value target during cloud penetration testing engagements.

Enterprise Scenario

CloudNova Technologies has been contracted to assess the Kubernetes environment of FinSecure Bank Ltd.

The enterprise operates:

12 Amazon EKS Clusters
850 Kubernetes Nodes
4,200 Pods
1,100 Microservices
GitOps Deployments
Amazon ECR
AWS Load Balancer Controller
ExternalDNS
Istio Service Mesh

Management wants to determine whether attackers could compromise Kubernetes workloads and gain unauthorized access to AWS resources.

Amazon EKS Architecture

Users

↓

AWS IAM

↓

Amazon EKS Control Plane

↓

Worker Nodes

↓

Pods

↓

Containers

↓

Service Accounts

↓

IAM Roles (IRSA)

↓

AWS Resources

Every layer contributes to the overall security posture of the cluster.

Amazon EKS Components

A typical Amazon EKS deployment includes:

Control Plane
Managed Node Groups
Self-managed Nodes
Pods
Deployments
Services
Namespaces
ConfigMaps
Secrets
RBAC
Network Policies
Ingress Controllers
Service Accounts
IAM Roles for Service Accounts (IRSA)

Each component should be reviewed during a penetration test.

Amazon EKS Attack Surface

Professional Cloud Penetration Testers typically assess:

Kubernetes API Server
RBAC Permissions
Service Accounts
ClusterRoles
ClusterRoleBindings
IAM Roles (IRSA)
Secrets
ConfigMaps
Admission Controllers
Worker Nodes
Containers
Ingress Controllers
Network Policies
Container Images

Kubernetes Shared Responsibility

AWS secures:

Kubernetes Control Plane
etcd availability
Control Plane infrastructure
Managed upgrades

Customers secure:

Worker Nodes
Applications
Pods
RBAC
IAM Integration
Secrets
Container Images
Network Policies

Most successful attacks exploit customer-managed configurations.

Enumeration

Professional assessments begin with cluster enumeration.

List clusters.

aws eks list-clusters

Describe cluster.

aws eks describe-cluster \
--name CLUSTER_NAME

Update kubeconfig.

aws eks update-kubeconfig \
--name CLUSTER_NAME

Verify connectivity.

kubectl get nodes

Enumerating Kubernetes Resources

Review cluster resources.

kubectl get namespaces

kubectl get pods -A

kubectl get deployments -A

kubectl get services -A

kubectl get daemonsets -A

kubectl get statefulsets -A

Document every workload running inside the cluster.

RBAC Assessment

RBAC determines who can perform actions inside Kubernetes.

Review:

kubectl get roles -A

kubectl get rolebindings -A

kubectl get clusterroles

kubectl get clusterrolebindings

Identify:

cluster-admin permissions
Wildcard permissions
Excessive privileges
Anonymous access

Service Accounts

Service Accounts provide workloads with Kubernetes identities.

Review.

kubectl get serviceaccounts -A

Determine:

Default Service Accounts
Privileged Service Accounts
Token mounting
IRSA usage

IAM Roles for Service Accounts (IRSA)

IRSA enables Kubernetes workloads to securely access AWS services.

Architecture:

Pod

↓

Service Account

↓

OIDC Provider

↓

IAM Role

↓

AWS APIs

↓

Amazon S3

↓

Secrets Manager

↓

Amazon DynamoDB

Review:

IAM Policies
Trust Relationships
Least Privilege
OIDC Configuration

Weak IRSA configurations can lead to AWS privilege escalation.

Kubernetes Secrets

Secrets often contain:

Database Credentials
API Keys
Tokens
TLS Certificates
OAuth Secrets

Review:

kubectl get secrets -A

Identify:

Excessive access
Plaintext secrets
Shared secrets
Missing secret rotation

ConfigMaps

Review ConfigMaps.

kubectl get configmaps -A

Look for:

Hardcoded credentials
Internal URLs
Debug settings
Sensitive configuration values

Sensitive information should not be stored in ConfigMaps.

Network Policies

Network Policies restrict Pod-to-Pod communication.

Review.

kubectl get networkpolicies -A

Determine:

Default deny policies
Namespace isolation
Micro-segmentation
Egress restrictions

Clusters without Network Policies often permit unrestricted lateral movement.

Privileged Workloads

Identify privileged containers.

kubectl get pods -A -o yaml

Review:

privileged: true
hostNetwork
hostPID
hostIPC
hostPath volumes
CAP_SYS_ADMIN
runAsUser: 0

These settings significantly increase risk.

Worker Node Assessment

Review:

AMI versions
Patch levels
SSH access
IAM Instance Profiles
Container Runtime
kubelet configuration

Compromising a worker node can expose every Pod scheduled on that node.

Container Image Review

Assess:

Base Images
Vulnerabilities
Image Signing
Registry Permissions

Example:

trivy image IMAGE_NAME

Review:

Critical CVEs
Root Containers
Outdated packages

Enterprise Attack Path

Public Application

↓

Pod Compromise

↓

Service Account

↓

IAM Role (IRSA)

↓

Amazon S3

↓

Sensitive Customer Data

Kubernetes attacks frequently extend beyond the cluster into AWS services.

Enterprise Assessment Workflow

Professional consultants typically follow this methodology.

Enumerate Cluster

↓

Review RBAC

↓

Review Service Accounts

↓

Review IRSA

↓

Review Secrets

↓

Review ConfigMaps

↓

Review Network Policies

↓

Review Privileged Pods

↓

Review Worker Nodes

↓

Review Container Images

↓

Identify Attack Paths

↓

Document Findings

Common Enterprise Findings

Examples include:

cluster-admin assigned broadly
Default Service Accounts in production
Administrator IAM Roles attached through IRSA
Missing Network Policies
Privileged Pods
Root Containers
Secrets stored in ConfigMaps
Public Kubernetes Dashboard
Unpatched Worker Nodes
Weak Ingress Controller configuration
Excessive RBAC permissions

Security Best Practices

Apply least-privilege RBAC.
Use dedicated Service Accounts for workloads.
Implement IRSA with minimal permissions.
Enable Pod Security Admission.
Enforce Network Policies.
Run containers as non-root users.
Store secrets using AWS Secrets Manager or external secret management solutions.
Continuously scan container images.
Audit Kubernetes API activity.
Regularly review ClusterRoleBindings.

Common Mistakes

Avoid:

Using the default Service Account.
Granting cluster-admin to application workloads.
Running privileged containers.
Using hostPath volumes unnecessarily.
Allowing unrestricted Pod-to-Pod communication.
Storing secrets in ConfigMaps.
Ignoring worker node patching.
Exposing the Kubernetes Dashboard publicly.

Knowledge Check

1. Why is Amazon EKS a valuable target during cloud penetration testing?

Answer: Amazon EKS often hosts critical business applications and integrates directly with AWS services through IAM Roles, making it a high-value target for attackers.

2. What is IRSA?

Answer: IAM Roles for Service Accounts (IRSA) allows Kubernetes Service Accounts to securely assume AWS IAM Roles without storing long-lived AWS credentials inside Pods.

3. Why should RBAC be reviewed during an assessment?

Answer: RBAC controls access to Kubernetes resources. Overly permissive roles can allow attackers to escalate privileges or gain cluster-wide control.

4. Why are privileged Pods considered high risk?

Answer: Privileged Pods have elevated access to the underlying host, increasing the likelihood of container escape, node compromise and lateral movement.

5. Why are Network Policies important?

Answer: Network Policies limit communication between Pods and namespaces, reducing the ability of attackers to move laterally after compromising a workload.

Key Takeaways

Amazon EKS extends the cloud attack surface beyond traditional AWS services into Kubernetes workloads.
RBAC, Service Accounts and IRSA are central to Kubernetes security.
Secrets, privileged containers and weak network segmentation are common enterprise findings.
Kubernetes assessments should evaluate both cluster security and AWS integration.
Understanding attack paths from Pods to AWS resources is essential for effective cloud penetration testing.

What’s Next?

In the next lesson, you will explore Lesson 09 — AWS Logging Evasion & Detection, where you will learn how attackers attempt to evade cloud monitoring, assess CloudTrail, CloudWatch, GuardDuty and Security Hub, and how defenders detect suspicious activity in enterprise AWS environments.

➡️ Next Lesson: Lesson 09 — AWS Logging Evasion & Detection