Lesson 10 — Enterprise Amazon EKS Security Architecture

Learning Objectives

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

Explain the purpose of an enterprise Amazon EKS security architecture
Design a multi-account and multi-cluster EKS operating model
Apply defence in depth across AWS and Kubernetes layers
Define security responsibilities between AWS, platform teams and application teams
Design secure identity and privileged-access workflows
Protect the Kubernetes API and EKS control plane access paths
Design segmented VPC, ingress and egress architectures
Apply pod-level AWS permissions and Kubernetes RBAC
Secure worker nodes, workloads and platform add-ons
Implement secure software-supply-chain controls
Integrate secrets management, runtime protection and SIEM monitoring
Build governance, compliance and exception-management processes
Design resilient backup and disaster-recovery controls
Create a phased enterprise EKS security implementation roadmap

Why This Matters

Individual security controls do not automatically create a secure platform.

An organisation may have:

Private worker nodes
Image scanning
Kubernetes RBAC
Network Policies
Security logging
Runtime monitoring
Backup systems

However, the environment may still remain exposed when those controls are:

Inconsistently implemented
Managed by different teams
Not connected
Not monitored
Not tested
Not supported by clear ownership
Bypassed through exceptions
Missing from some clusters

An enterprise security architecture connects people, processes and technologies into one operating model.

Individual Security Tools

Without Integration

↓

Security Gaps

Inconsistent Controls

Limited Accountability

Integrated Security Architecture

↓

Prevent

↓

Detect

↓

Respond

↓

Recover

↓

Continuously Improve

For a Cloud Security Engineer, the objective is not simply to secure one EKS cluster.

The objective is to create a repeatable architecture that can protect:

Multiple AWS accounts
Multiple Regions
Multiple EKS clusters
Multiple business units
Hundreds of applications
Development, testing and production environments

What is Enterprise EKS Security Architecture?

Enterprise Amazon EKS security architecture is the structured design of security controls, responsibilities, trust boundaries and operational processes used to protect Amazon EKS environments at scale.

It covers:

AWS organisation governance
Account isolation
Network architecture
Identity and access
Kubernetes authorization
Worker-node protection
Workload hardening
Container-image security
CI/CD security
Secrets management
Runtime security
Logging and monitoring
Incident response
Backup and disaster recovery
Compliance reporting
Security exception management

Security Architecture Objectives

A mature architecture should provide:

Strong Isolation

+

Least Privilege

+

Secure Defaults

+

Central Visibility

+

Automated Governance

+

Operational Resilience

Enterprise Design Principles

Defence in Depth

Do not depend on one security control.

Identity Control

+

Network Control

+

Workload Control

+

Runtime Detection

+

Logging

+

Incident Response

If one control fails, another control should reduce the impact.

Least Privilege

Grant users, workloads and automation systems only the permissions required to perform approved activities.

Zero Trust

Do not automatically trust a request because it originates inside the VPC or cluster.

Every request should be:

Authenticated
Authorized
Encrypted where required
Logged
Continuously evaluated

Secure by Default

New clusters and namespaces should automatically inherit approved security controls.

Separation of Duties

Administrative responsibilities should be divided between teams.

Automation First

Security controls should be implemented through:

Infrastructure as Code
GitOps
Policy as Code
Automated validation
Continuous monitoring

Immutable Infrastructure

Replace compromised or outdated infrastructure rather than manually repairing it.

Assume Breach

Design controls with the expectation that:

A Pod may be compromised.
Credentials may be stolen.
A software dependency may be malicious.
An administrator account may be misused.

Shared Responsibility Model

AWS protects the infrastructure supporting the managed EKS control plane.

The customer remains responsible for the secure use and configuration of the service.

Security Area	AWS Responsibility	Customer Responsibility
Managed control plane infrastructure	Operate and protect underlying infrastructure	Configure secure cluster access
Control plane availability	Operate managed control plane components	Design application and node resilience
Kubernetes API	Operate API infrastructure	Manage authentication and authorization
Worker nodes	Not managed unless using supported managed capabilities	Secure OS, IAM, networking and lifecycle
Workloads	Not managed by AWS	Secure Pods, images and applications
Data	Protect AWS service infrastructure	Classify, encrypt and govern data
Logging	Provide logging capabilities	Enable, retain and monitor logs
Incident response	Protect AWS infrastructure	Investigate customer workloads and configurations

Enterprise Responsibility Model

Cloud Security Team

Defines Security Standards

↓

Platform Engineering Team

Builds and Operates the EKS Platform

↓

Application Teams

Secure and Operate Their Workloads

↓

SOC

Monitors and Investigates Security Events

↓

Governance and Compliance

Validates Control Effectiveness

Example Responsibility Matrix

Activity	Cloud Security	Platform Team	Application Team	SOC
EKS security baseline	Accountable	Consulted	Informed	Consulted
Cluster provisioning	Consulted	Responsible	Informed	Informed
Application image security	Consulted	Provides platform	Responsible	Informed
Runtime alert investigation	Consulted	Supports	Supports	Responsible
RBAC governance	Accountable	Responsible	Requests access	Monitors
Secrets rotation	Defines standard	Provides integration	Responsible	Monitors
Incident containment	Supports	Responsible for platform	Responsible for app	Coordinates

Enterprise Security Domains

Enterprise Amazon EKS Security

├── Organisation and Account Governance
├── Identity and Access Management
├── Network Security
├── Cluster and Node Hardening
├── Workload Security
├── Software Supply Chain
├── Secrets and Data Protection
├── Runtime Security
├── Logging and Monitoring
├── Incident Response
├── Backup and Disaster Recovery
└── Compliance and Governance

Multi-Account Architecture

AWS accounts provide strong isolation boundaries.

A mature organisation should avoid operating all EKS clusters in one AWS account.

AWS Organization

├── Security OU
│   ├── Security Tooling Account
│   └── Log Archive Account
│
├── Infrastructure OU
│   ├── Network Account
│   ├── Shared Services Account
│   └── CI/CD Account
│
├── Production OU
│   ├── Payments Production Account
│   ├── Customer Platform Production Account
│   └── Analytics Production Account
│
└── Non-Production OU
    ├── Development Account
    ├── Testing Account
    └── Sandbox Account

Benefits of Multi-Account Design

Multi-account architecture provides:

Stronger isolation
Reduced blast radius
Independent service quotas
Clear billing boundaries
Environment separation
Easier compliance scoping
Separate administrative roles
Centralized security monitoring

Organisational Units

AWS Organizations can group accounts into Organisational Units based on:

Environment
Business unit
Regulatory scope
Workload criticality
Platform function
Geographic requirements

Service Control Policies

Service Control Policies establish permission guardrails for AWS accounts.

Example guardrails may:

Prevent disabling CloudTrail
Restrict unsupported AWS Regions
Prevent public S3 buckets
Restrict creation of internet-facing resources
Prevent deletion of protected backup vaults
Require approved role usage
Restrict changes to security tooling

SCPs do not directly grant permissions.

They define the maximum permissions available within an account.

Central Security Accounts

A mature AWS organisation commonly includes:

Security Tooling Account

Used for:

Security Hub administration
GuardDuty administration
Inspector aggregation
Security automation
Investigation tooling
Finding aggregation

Log Archive Account

Used for:

CloudTrail archives
Security logs
EKS audit logs
Network logs
Long-term evidence
Compliance retention

Network Account

Used for:

Transit Gateway
Central DNS
Network Firewall
Egress controls
Shared VPC connectivity
Hybrid connectivity

Multi-Cluster Strategy

Enterprises must decide how many EKS clusters to operate.

Options include:

Cluster per environment
Cluster per application
Cluster per business unit
Cluster per regulatory boundary
Shared multi-tenant clusters
Dedicated high-risk clusters

Shared Cluster Versus Dedicated Cluster

Shared Cluster	Dedicated Cluster
Lower infrastructure overhead	Stronger isolation
Higher resource utilisation	Smaller blast radius
More complex tenancy controls	Easier compliance scoping
Shared add-ons and operations	Independent upgrades
Greater noisy-neighbour risk	Increased operational cost
Requires strong namespace governance	Clear workload ownership

When to Use Dedicated Clusters

Dedicated clusters should be considered for:

Regulated workloads
Payment environments
Internet-facing critical services
Highly sensitive data
Untrusted tenants
Workloads requiring special Kubernetes versions
Workloads requiring privileged components
Independent recovery requirements

Cluster Classification

Every cluster should be classified.

Classification	Example
Critical Production	Banking or payment platform
Standard Production	Customer-facing business service
Internal Production	Employee application
Testing	Pre-production validation
Development	Developer workloads
Sandbox	Temporary experimentation

Security requirements should increase with workload criticality.

Enterprise Reference Architecture

Users and Administrators

↓

Enterprise Identity Provider

↓

AWS IAM Identity Center

↓

Temporary IAM Roles with MFA

↓

Private Administrative Network

↓

VPN, Direct Connect or Approved Access Path

↓

Private or Restricted Amazon EKS API Endpoint

↓

EKS Access Entries

↓

Kubernetes RBAC

↓

Admission Control and Policy Enforcement

↓

Amazon EKS Workloads

├── Private Worker Nodes
├── Managed Node Groups
├── Bottlerocket or Approved AMIs
├── Dedicated Service Accounts
├── EKS Pod Identity or IRSA
├── Pod Security Admission
├── Network Policies
├── Signed Container Images
└── External Secrets

↓

Runtime Security and Observability

↓

Central Security Account and SIEM

↓

SOC and Incident Response

Security Trust Boundaries

Trust boundaries identify where authentication, authorization and inspection must occur.

Internet Boundary

↓

AWS Account Boundary

↓

VPC Boundary

↓

EKS Cluster Boundary

↓

Namespace Boundary

↓

Pod Boundary

↓

Container Process Boundary

Crossing each boundary should require explicit controls.

Management Plane

The management plane includes systems used to provision and administer EKS.

Examples include:

AWS Management Console
AWS CLI
Terraform
CloudFormation
CI/CD pipelines
GitOps controllers
Kubernetes administrative tools
Security automation

A compromised management plane may affect every cluster.

Management Plane Security

Apply:

MFA
Temporary credentials
Dedicated administrative roles
Privileged access management
Restricted networks
Session logging
Approval workflows
Infrastructure as Code
Protected Git repositories
Strong CI/CD controls

Administrative Access Architecture

Administrator

↓

Enterprise Identity Provider

↓

IAM Identity Center

↓

MFA

↓

Temporary AWS Role

↓

Approved Network Path

↓

EKS Access Entry

↓

Kubernetes RBAC

Human Identity Security

Human access should use:

Enterprise federation
Individual accounts
MFA
Temporary sessions
Role-based access
Session expiration
Central access reviews
Conditional access where available

Avoid:

Shared IAM users
Permanent access keys
Shared kubeconfig files
Long-lived Kubernetes tokens
Permanent cluster-admin access

EKS Access Entries

EKS access entries provide an AWS API-based method for managing IAM principal access to an EKS cluster.

Use access entries to:

Add approved IAM roles
Associate access policies
Manage cluster access centrally
Improve change visibility through CloudTrail
Reduce manual management of legacy access mappings

Access Entry Model

IAM Principal

↓

EKS Access Entry

↓

EKS Access Policy or Kubernetes Group

↓

Kubernetes Authorization

↓

Approved Cluster Resources

Kubernetes RBAC Architecture

Enterprise Role

↓

EKS Access Entry

↓

Kubernetes Group

↓

RoleBinding

↓

Namespace Role

↓

Approved Actions

Prefer namespace-scoped permissions for routine work.

Privileged Access Management

Administrative access should be:

Time-limited
Approved
Logged
Reviewed
Automatically removed
Used only when required

Just-in-Time Access

Access Request

↓

Manager or Security Approval

↓

Temporary Privileged Role

↓

MFA Authentication

↓

Time-Limited Session

↓

Activity Logged

↓

Access Automatically Expires

Break-Glass Access

A break-glass process provides emergency access when standard access systems are unavailable.

Requirements should include:

Strong authentication
Restricted custodians
Recorded justification
Immediate alerting
Session logging
Automatic expiry
Post-event review
Credential rotation

Break-glass access should never become a normal administrative method.

Workload Identity

Applications should not use:

Static AWS access keys
Human credentials
Broad worker-node roles
Shared application credentials

Use:

EKS Pod Identity
IAM Roles for Service Accounts
Dedicated Kubernetes Service Accounts
Least-privilege IAM roles

Workload Identity Architecture

Application Pod

↓

Dedicated Kubernetes Service Account

↓

EKS Pod Identity Association

↓

Dedicated IAM Role

↓

Approved AWS Service

Node Role Versus Pod Role

Node IAM Role	Pod IAM Role
Used by node-level services	Used by a specific workload
Shared by workloads if improperly designed	Assigned to a Kubernetes Service Account
Broad access creates major risk	Supports granular least privilege
Required for node operations	Required for application AWS access

Identity Governance

Review:

IAM role usage
EKS access entries
ClusterRoleBindings
RoleBindings
Service Accounts
Pod Identity associations
IRSA trust policies
Unused identities
Dormant access
Overly broad policies

Network Security Architecture

Internet

↓

Amazon CloudFront or External Entry Layer

↓

AWS WAF

↓

Public Application Load Balancer

↓

Private EKS Worker Nodes

↓

Application Pods

↓

Internal Services and Databases

↓

Controlled Egress

↓

AWS Network Firewall, Proxy or NAT Gateway

VPC Design

Production EKS clusters should use a documented VPC design.

Typical architecture:

VPC

├── Public Subnets
│   ├── Internet-Facing Load Balancers
│   └── NAT Gateways
│
├── Private Application Subnets
│   ├── EKS Worker Nodes
│   └── Application Pods
│
└── Restricted Data Subnets
    ├── Databases
    ├── Caches
    └── Internal Services

Private Worker Nodes

Production worker nodes should generally:

Run in private subnets
Avoid public IP addresses
Use controlled outbound access
Use approved VPC endpoints
Use restricted Security Groups

EKS API Endpoint Architecture

Options include:

Public endpoint
Private endpoint
Public and private endpoint

For sensitive production clusters, use a private endpoint where operationally feasible.

If public access is required:

Restrict approved CIDR ranges.
Do not use unrestricted internet access.
Require federated IAM access.
Require MFA.
Monitor authenticator and audit logs.

Administrative Network Paths

Approved access may come from:

Corporate network
Site-to-Site VPN
AWS Client VPN
Direct Connect
Controlled administrative VPC
Approved bastion or management environment

Security Groups

Security Groups should be designed for:

EKS control plane communication
Worker-node communication
Load balancer traffic
Database access
Management tooling
Security agents

Avoid broad rules such as:

Source: 0.0.0.0/0

Ports: All

Protocol: All

Security Groups for Pods

Security Groups for Pods may provide AWS network controls directly at the Pod interface level for supported configurations.

Use cases include:

Database access isolation
Regulated workload segmentation
Application-specific network permissions
Integration with existing VPC security models

Kubernetes Network Policies

Network Policies control Pod-level traffic.

Start with:

Default Deny

↓

Explicitly Allow Required Traffic

Default-Deny Example

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments

spec:
  podSelector: {}

  policyTypes:
    - Ingress
    - Egress

Application Communication Model

Frontend Namespace

↓

Explicit Network Policy

↓

Payment API Namespace

↓

Explicit Network Policy

↓

Database

Ingress Security

Approved ingress architecture should include:

Approved IngressClass
TLS
AWS Certificate Manager
AWS WAF where required
Load balancer access logging
Restricted hostnames
Approved ports
Authentication
Rate limiting where applicable
Secure HTTP headers

Public Exposure Governance

Control creation of:

Public LoadBalancer Services
Public Ingress resources
NodePort Services
External IP addresses
Host ports
Internet-facing endpoints

Admission policies should block unapproved public exposure.

Egress Security

Unrestricted outbound access allows:

Malware downloads
Command-and-control traffic
Data exfiltration
Access to unapproved services
Bypass of internal security controls

Use:

Network Policies
Security Groups
NAT controls
VPC endpoints
Egress proxies
AWS Network Firewall
DNS filtering
Flow logging

Private AWS Service Access

Use VPC endpoints for services such as:

Amazon ECR API
Amazon ECR Docker
Amazon S3
AWS STS
AWS KMS
AWS Secrets Manager
CloudWatch Logs
Systems Manager

Private Pod

↓

VPC Endpoint

↓

AWS Service

DNS Security

Protect DNS through:

CoreDNS availability
DNS query monitoring
Approved upstream resolvers
Route 53 Resolver logs
DNS firewall controls
Detection of suspicious domains
Restricted CoreDNS configuration changes

Worker-Node Architecture

Worker-node options may include:

EKS Managed Node Groups
Self-managed nodes
Bottlerocket nodes
AWS Fargate
EKS Auto Mode capabilities where appropriate

The choice should be based on:

Security requirements
Workload compatibility
Operational maturity
Performance
Compliance
Cost
Required host access

Worker-Node Hardening Baseline

Production worker nodes should use:

Private subnets
Approved EKS-optimised or hardened images
Encrypted EBS volumes
IMDSv2
Restricted instance metadata access
Minimal IAM permissions
Restricted Security Groups
Automated patching
Immutable replacement
Runtime monitoring
No unnecessary SSH access

Managed Node Groups

Managed Node Groups can simplify:

Node provisioning
Lifecycle management
Version upgrades
Integration with EKS
Replacement operations

Security teams must still govern:

AMI selection
Launch templates
IAM roles
Security Groups
Instance types
Labels and taints
Update strategy

Bottlerocket

Bottlerocket is a container-focused operating system that can reduce the traditional host-management surface.

Potential benefits include:

Minimal operating-system packages
Immutable design
Transactional updates
Reduced administrative tools
Container-focused security model

Operational teams should test compatibility and support procedures before adoption.

Node-Group Segmentation

Amazon EKS Cluster

├── System Node Group
│   ├── CoreDNS
│   ├── Monitoring
│   └── Policy Controllers
│
├── Standard Application Node Group
│
├── Sensitive Workload Node Group
│
├── GPU Node Group
│
└── Approved Privileged Tooling Node Group

Use:

Taints
Tolerations
Node selectors
Affinity
Dedicated IAM roles
Dedicated Security Groups
Separate scaling policies

Immutable Node Lifecycle

Security Update Released

↓

Approved Image Built or Selected

↓

New Node Group Created

↓

Workloads Rescheduled

↓

Old Nodes Drained

↓

Old Node Group Removed

Avoid manually patching long-lived production nodes.

Kubernetes Control Architecture

Deployment Request

↓

Kubernetes API

↓

Authentication

↓

Authorization

↓

Admission Control

↓

Resource Stored

↓

Scheduler

↓

Worker Node

↓

Runtime Monitoring

Security validation should occur before a workload runs.

Namespace Architecture

Namespaces provide a logical administrative boundary.

A namespace standard may require:

Owner labels
Environment labels
Data-classification labels
Pod Security Admission labels
ResourceQuotas
LimitRanges
Default-deny Network Policies
Dedicated Service Accounts
Approved RBAC bindings

Namespace Example

payments-production

├── Payment API
├── Fraud Connector
├── Dedicated Service Accounts
├── Restricted Pod Security
├── Default-Deny Network Policies
├── ResourceQuota
└── Namespace-Scoped RBAC

Namespaces do not provide complete isolation by themselves.

Sensitive or untrusted tenants may require separate clusters or AWS accounts.

Pod Security Admission

Use Kubernetes Pod Security Admission to enforce Pod Security Standards.

Profiles include:

Privileged
Baseline
Restricted

Production application namespaces should target the Restricted profile where workloads are compatible.

Pod Security Rollout

Warn

↓

Audit

↓

Remediate

↓

Enforce

Secure Pod Baseline

A secure workload should normally:

Run as non-root
Disable privilege escalation
Drop unnecessary Linux capabilities
Use RuntimeDefault seccomp
Use a read-only root filesystem
Avoid host namespaces
Avoid HostPath
Avoid privileged mode
Define resource requests and limits
Use a dedicated Service Account

Secure Pod Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  namespace: payments

spec:
  replicas: 3

  selector:
    matchLabels:
      app: payment-api

  template:
    metadata:
      labels:
        app: payment-api

    spec:
      serviceAccountName: payment-api
      automountServiceAccountToken: false

      securityContext:
        runAsNonRoot: true

        seccompProfile:
          type: RuntimeDefault

      containers:
        - name: payment-api
          image: 123456789012.dkr.ecr.example-region.amazonaws.com/payment-api@sha256:approveddigest

          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true

            capabilities:
              drop:
                - ALL

          resources:
            requests:
              cpu: 200m
              memory: 256Mi

            limits:
              cpu: 1
              memory: 1Gi

Admission Control Architecture

Developer Deployment

↓

Kubernetes API

↓

Pod Security Admission

↓

Enterprise Policy Engine

↓

Image Verification

↓

Approved Workload Runs

Enterprise Policy Engines

Organisations may use:

Kyverno
OPA Gatekeeper
Native Kubernetes admission policies
Custom admission webhooks

High-Value Admission Policies

Enforce:

Approved image registries
Immutable image digests
Required image signatures
Non-root execution
Restricted capabilities
No privileged containers
No HostPath mounts
No host namespaces
Resource requests and limits
Approved IngressClass
Approved storage classes
Required ownership labels
Dedicated Service Accounts
Restricted public services

Policy Failure Design

Admission controls should be:

Highly available
Monitored
Protected by PodDisruptionBudgets
Deployed across Availability Zones
Version-controlled
Tested before upgrades
Protected with restricted RBAC

The organisation must decide whether individual policies should fail open or fail closed.

Secure Software Supply Chain

Developer

↓

Source Repository

↓

Pull Request Review

↓

CI Pipeline

↓

Software Composition Analysis

↓

Static Security Testing

↓

Container Build

↓

Image Scan

↓

SBOM Generation

↓

Image Signing

↓

Amazon ECR

↓

Admission Verification

↓

Amazon EKS

Source-Code Security

Protect repositories using:

Individual identities
MFA
Protected branches
Pull-request reviews
CODEOWNERS
Secret scanning
Signed commits where required
Restricted automation tokens
Audit logging

CI/CD Identity

CI/CD pipelines should use:

Temporary credentials
Workload federation
Dedicated deployment roles
Least-privilege permissions
Environment-specific roles

Avoid storing permanent AWS access keys in pipeline variables.

Pipeline Security Controls

Require:

Static application security testing
Dependency scanning
Secret scanning
Infrastructure-as-Code scanning
Kubernetes manifest scanning
Container-image scanning
SBOM creation
Image signing
Approval gates
Deployment evidence

Container Registry Architecture

Build Pipeline

↓

Security Scan

↓

Image Signing

↓

Approved Amazon ECR Repository

↓

Admission Verification

↓

Production EKS Cluster

Amazon ECR Governance

Apply:

Private repositories
Encryption
Image scanning
Tag immutability
Lifecycle policies
Repository policies
Cross-account controls
CloudTrail monitoring
Replication where required

Immutable Images

Avoid:

image: payment-api:latest

Prefer:

image: payment-api@sha256:approveddigest

A digest identifies exact image content.

Image Signing

Image signing provides evidence that an approved process produced the image.

Approved Build

↓

Image Created

↓

Image Scanned

↓

Image Signed

↓

Signature Verified

↓

Deployment Allowed

Software Bill of Materials

An SBOM identifies the packages and components contained in an application or image.

It supports:

Vulnerability response
Licence analysis
Supply-chain investigation
Component ownership
Impact assessment

Secrets Architecture

Application Pod

↓

Kubernetes Service Account

↓

EKS Pod Identity or IRSA

↓

AWS Secrets Manager

↓

AWS KMS

↓

Read-Only Secret Delivery

Secrets Principles

Never store plaintext secrets in Git.
Never embed credentials in images.
Avoid long-lived AWS access keys.
Use pod-level identity.
Grant access to specific secrets.
Rotate credentials.
Monitor retrieval.
Revoke compromised credentials.

Secrets Store CSI Architecture

Pod

↓

Secrets Store CSI Driver

↓

AWS Secrets and Configuration Provider

↓

EKS Pod Identity

↓

AWS Secrets Manager

↓

Mounted Read-Only File

Kubernetes Secret Use

When native Kubernetes Secrets are required:

Enable encryption protection.
Restrict RBAC.
Restrict Pod creation permissions.
Monitor Secret access.
Avoid broad list and watch.
Define rotation.
Avoid exposure through environment variables where practical.

Data Protection Architecture

Data protection should cover:

Data in transit
Data at rest
Backups
Secrets
Logs
Container registries
Persistent storage
Application databases

Encryption in Transit

Use:

HTTPS
TLS ingress
Service-to-service TLS where required
Encrypted database connections
Secure AWS API endpoints
Certificate lifecycle management

Encryption at Rest

Encrypt:

EBS volumes
EFS filesystems
Kubernetes Secret data where required
Secrets Manager secrets
CloudWatch Logs
S3 backup buckets
ECR repositories
Databases
Snapshots

AWS KMS Architecture

Protected Resource

↓

AWS KMS Key

↓

Key Policy

↓

Approved IAM Role

↓

CloudTrail Monitoring

KMS Governance

Define:

Key ownership
Key administrators
Key users
Rotation
Deletion protection
Separation of duties
Cross-account access
Monitoring

Platform Add-On Security

Critical add-ons may include:

Amazon VPC CNI
CoreDNS
kube-proxy
EBS CSI Driver
EFS CSI Driver
AWS Load Balancer Controller
EKS Pod Identity Agent
Karpenter
Policy engines
Monitoring collectors
Runtime agents
GitOps controllers

Add-On Governance Register

Attribute	Requirement
Owner	Named platform owner
Version	Approved and supported
Source	Trusted repository
IAM	Dedicated least-privilege role
RBAC	Reviewed permissions
Availability	Multiple replicas where applicable
Monitoring	Health and performance alerts
Upgrade	Tested lifecycle
Recovery	Rollback procedure

Protect High-Privilege Add-Ons

High-privilege platform components should:

Run in protected namespaces
Use dedicated node groups where appropriate
Have restricted RBAC
Use dedicated IAM roles
Use immutable image references
Be deployed through GitOps
Generate health alerts
Have approved exception documentation

Runtime Security Architecture

Running Workloads

↓

Kernel and Runtime Events

↓

GuardDuty Runtime Monitoring or Runtime Agent

↓

Security Findings

↓

Security Hub

↓

Enterprise SIEM

↓

SOC Investigation

Runtime Detection Use Cases

Detect:

Reverse shells
Unexpected shell execution
Privilege escalation
Cryptomining
Malware
Container escape indicators
Sensitive file access
Credential theft
Unexpected outbound connections
Security-agent tampering

Defence Against Compromised Pods

Assume an application Pod is compromised.

Controls should limit the attacker through:

Non-Root Container

+

Read-Only Filesystem

+

Dropped Capabilities

+

Restricted Service Account

+

Pod-Level IAM Role

+

Default-Deny Network Policy

+

Restricted Egress

+

Runtime Monitoring

Logging Architecture

EKS Control Plane Logs

+

Kubernetes Audit Logs

+

CloudTrail

+

Application Logs

+

Node Logs

+

Runtime Findings

+

VPC Flow Logs

+

Load Balancer Logs

↓

Central Logging Account

↓

SIEM

↓

SOC

Required EKS Control Plane Logs

Consider enabling:

API Server
Audit
Authenticator
Controller Manager
Scheduler

CloudTrail and Kubernetes Audit Logs

CloudTrail

Records AWS API Activity

Kubernetes Audit Logs

Record Kubernetes API Activity

Both are required for broad visibility.

Security Monitoring Use Cases

Monitor for:

Cluster access changes
New cluster-admin bindings
Secret access
Privileged Pod creation
Pod execution
Public endpoint changes
Public LoadBalancer creation
Network Policy deletion
Admission-controller changes
Runtime threats
Logging disablement
Backup deletion
KMS key changes

Security Operations Architecture

Security Alert

↓

SIEM Correlation

↓

SOC Triage

↓

Platform and Application Context

↓

Incident Created

↓

Containment

↓

Investigation

↓

Recovery

↓

Lessons Learned

Alert Enrichment

Alerts should include:

AWS account
Region
Cluster
Namespace
Pod
Container
Image
Service Account
IAM role
User identity
Source address
Business owner
Data classification
Runbook

Automated Response

Some events may support automated response.

Examples include:

Quarantine a workload
Remove a malicious network path
Revoke a Pod Identity association
Block an image digest
Scale a compromised Deployment to zero
Capture evidence
Open an incident
Notify the SOC

Automation should be:

Approved
Tested
Reversible
Logged
Scoped to avoid excessive impact

Incident Containment

Possible containment actions include:

Isolate a namespace.
Apply emergency Network Policies.
Remove external exposure.
Scale a Deployment to zero.
Cordon affected nodes.
Revoke credentials.
Disable compromised IAM roles.
Replace worker nodes.
Block malicious image digests.

Evidence Collection

Collect:

Kubernetes audit logs
CloudTrail events
Runtime alerts
Container logs
Node telemetry
Process information
Network flows
Image details
Deployment manifests
IAM activity
Recent changes

Incident Response Runbooks

Required runbooks may include:

Compromised Pod
Privileged workload
Kubernetes credential theft
Suspicious Secret access
Container escape
Malicious image
Public exposure
Compromised worker node
Cryptomining
Audit-log failure
Cluster administrator compromise

Backup Architecture

Kubernetes Resources

↓

Velero or Approved Backup Tool

↓

Protected S3 Storage

Persistent Data

↓

EBS, EFS or Database Backup

↓

AWS Backup Vault

↓

Cross-Account and Cross-Region Copy

↓

Tested Recovery

Recovery Principles

Infrastructure should be reproducible through code.
Kubernetes state should be recoverable through GitOps and backup.
Persistent data should have workload-specific backups.
Secrets should be recoverable from authoritative secret stores.
Container images should be available from protected registries.
Recovery should be tested.

Disaster-Recovery Architecture

Primary Region

├── Production EKS Cluster
├── Application Data
├── ECR Images
└── Security Configuration

↓

Replication and Backup

↓

Secondary Region

├── Predefined Infrastructure
├── Recovery EKS Cluster
├── Replicated Images
└── Restored Application Data

Recovery Strategy Options

Strategy	Description	Typical Recovery Profile
Backup and Restore	Rebuild after disruption	Higher RTO
Pilot Light	Core services preconfigured	Moderate RTO
Warm Standby	Reduced-capacity environment running	Lower RTO
Active-Active	Multiple Regions actively serving	Lowest RTO and greatest complexity

Compliance Architecture

Security Baseline

↓

Infrastructure as Code

↓

Policy as Code

↓

Automated Validation

↓

Central Findings

↓

Evidence Repository

↓

Compliance Reporting

Compliance Frameworks

Depending on organisational requirements, EKS controls may map to:

CIS Kubernetes Benchmark
CIS AWS Foundations Benchmark
NIST Cybersecurity Framework
NIST SP 800-53
ISO 27001
PCI DSS
SOC 2
HIPAA
Internal security policies

Compliance requirements depend on the organisation, jurisdiction and workload.

Continuous Compliance

Avoid one-time manual assessments.

Use:

AWS Config
Security Hub
Policy reports
Infrastructure scanning
Admission policies
Runtime findings
Cluster posture tools
Central dashboards
Scheduled reviews

Security Baseline as Code

The standard cluster configuration should be stored as code.

Enterprise Baseline Repository

├── Terraform Modules
├── EKS Cluster Configuration
├── IAM Policies
├── Network Policies
├── Admission Policies
├── Logging Configuration
├── Monitoring Rules
└── Compliance Tests

Platform Landing Zone

An enterprise EKS landing zone provides approved reusable components.

It may include:

AWS account structure
VPC architecture
EKS Terraform module
Standard node groups
Logging configuration
Pod Security Admission
Policy engine
Runtime monitoring
Secrets integration
Backup integration
SIEM forwarding

Golden Cluster Pattern

Approved EKS Blueprint

↓

Automated Cluster Provisioning

↓

Mandatory Security Add-Ons

↓

Baseline Policies

↓

Continuous Validation

↓

Production Approval

Cluster Provisioning Pipeline

Cluster Request

↓

Business and Data Classification

↓

Architecture Approval

↓

Infrastructure Pipeline

↓

Security Validation

↓

Cluster Deployment

↓

Baseline Add-Ons

↓

Operational Readiness Review

↓

Production Handover

Production Readiness Review

Before production use, validate:

Account ownership
Cluster classification
API endpoint restrictions
Identity federation
Access entries
RBAC
Node hardening
Pod Security Admission
Network Policies
Image scanning
Secrets management
Logging
Monitoring
Runtime protection
Backup
Incident runbooks
Recovery testing

Security Exception Management

Some workloads may require temporary deviations.

Every exception should include:

Control Requirement:

Affected Cluster:

Namespace and Workload:

Business Justification:

Security Risk:

Compensating Controls:

Owner:

Approver:

Expiry Date:

Remediation Plan:

Exception Lifecycle

Exception Requested

↓

Risk Assessed

↓

Compensating Controls Defined

↓

Time-Limited Approval

↓

Continuous Monitoring

↓

Remediation

↓

Exception Closed

Security Metrics

Metric	Target
Production clusters using approved baseline	100%
Clusters with required control plane logging	100%
Production namespaces using Restricted PSA	100%
Unapproved cluster-admin bindings	0
Public API endpoints without restrictions	0
Critical image vulnerabilities beyond SLA	0
Workloads using static AWS credentials	0
Production namespaces without Network Policies	0
Unapproved privileged workloads	0
Expired security exceptions	0
Clusters connected to SIEM	100%
Tested production recovery plans	100%

Security Dashboards

Executive Dashboard

Show:

Overall cluster compliance
Critical findings
Major incidents
Unsupported versions
High-risk exceptions
Recovery readiness

Cloud Security Dashboard

Show:

Public endpoint exposure
Identity findings
RBAC risk
Vulnerable images
Runtime findings
Logging coverage
Policy violations

Platform Dashboard

Show:

Cluster health
Add-on health
Node status
Upgrade status
Network capacity
Backup success
Monitoring coverage

Application Dashboard

Show:

Image vulnerabilities
Namespace policy compliance
Application availability
Secret-rotation status
Workload runtime alerts
Service-level indicators

Common Architecture Mistakes

One AWS Account for Every Environment

Risk: A compromise or configuration error affects many workloads.

Control: Separate environments and critical workloads into appropriate accounts.

Shared Cluster-Admin Access

Risk: Reduced accountability and excessive privilege.

Control: Use individual federated identities and time-limited privileged access.

Broad Worker-Node IAM Roles

Risk: A compromised Pod may inherit excessive AWS permissions.

Control: Use EKS Pod Identity or IRSA for workloads.

Public EKS API Without Restrictions

Risk: Expanded control-plane attack surface.

Control: Use private access or approved CIDR restrictions.

No Default-Deny Networking

Risk: Compromised workloads may move laterally.

Control: Implement default-deny Network Policies.

Images Deployed by Mutable Tag

Risk: Unapproved content may replace trusted workloads.

Control: Use immutable digests and signature verification.

Secrets Stored in Git

Risk: Credentials remain available in repository history.

Control: Use external secrets management and rotate exposed credentials.

Policy Enforcement Without Availability Design

Risk: Admission-controller failure may block all deployments or create enforcement gaps.

Control: Design highly available and monitored policy services.

Runtime Alerts Not Connected to SOC

Risk: Threats are detected but not investigated.

Control: Integrate findings with SIEM workflows and runbooks.

Backups Never Tested

Risk: Recovery fails during a real disaster.

Control: Conduct regular restore and disaster-recovery exercises.

Security Exceptions Without Expiry

Risk: Temporary weaknesses become permanent.

Control: Require expiry and remediation plans.

Different Standards for Every Cluster

Risk: Security posture becomes inconsistent and difficult to operate.

Control: Create a reusable enterprise EKS landing zone.

Enterprise Security Architecture Layers

Layer 1 — AWS Organisation

Accounts, OUs, SCPs and central security services

↓

Layer 2 — Identity

Federation, MFA, access entries, RBAC and pod identity

↓

Layer 3 — Network

VPCs, private subnets, endpoints, Security Groups and Network Policies

↓

Layer 4 — Cluster

Control plane access, logging, add-ons and configuration

↓

Layer 5 — Nodes

Hardened images, private nodes, IAM and immutable lifecycle

↓

Layer 6 — Workloads

Pod security, resource controls and admission policies

↓

Layer 7 — Supply Chain

Source, CI/CD, scanning, SBOMs, signing and ECR

↓

Layer 8 — Data

Encryption, KMS, secrets and persistent storage

↓

Layer 9 — Detection

Audit logs, runtime security, GuardDuty and SIEM

↓

Layer 10 — Resilience

Backup, recovery, incident response and business continuity

Enterprise Implementation Roadmap

Phase 1 — Discover and Classify

Inventory AWS accounts.
Inventory EKS clusters.
Identify owners.
Classify environments.
Classify data.
Identify regulatory requirements.
Document current controls.
Identify architecture gaps.

Phase 2 — Establish Governance

Define the EKS security standard.
Define account strategy.
Define cluster-classification requirements.
Establish ownership.
Define RACI responsibilities.
Create exception-management processes.
Define security metrics.

Phase 3 — Build the AWS Foundation

Implement AWS Organizations.
Create security and log archive accounts.
Establish SCP guardrails.
Centralise CloudTrail.
Delegate security services.
Establish central network services.
Define approved AWS Regions.

Phase 4 — Build the Secure EKS Landing Zone

Create approved Infrastructure-as-Code modules.
Standardise VPC design.
Standardise API endpoint access.
Define node-group patterns.
Enable control plane logging.
Install approved add-ons.
Apply mandatory tags and metadata.

Phase 5 — Implement Identity Security

Integrate IAM Identity Center.
Require MFA.
Implement EKS access entries.
Remove unnecessary legacy access mappings.
Apply least-privilege RBAC.
Introduce just-in-time administration.
Establish break-glass access.
Implement EKS Pod Identity or IRSA.

Phase 7 — Harden Clusters and Workloads

Use approved node images.
Enforce IMDSv2.
Encrypt worker-node storage.
Implement immutable node replacement.
Apply Pod Security Admission.
Deploy enterprise admission policies.
Restrict privileged workloads.
Apply ResourceQuotas and LimitRanges.

Phase 8 — Secure the Software Supply Chain

Protect source repositories.
Remove long-lived pipeline credentials.
Add code and dependency scanning.
Scan Infrastructure as Code.
Scan container images.
Generate SBOMs.
Sign images.
Verify signatures during admission.
Restrict production registries.

Phase 9 — Protect Secrets and Data

Inventory secrets.
Use Secrets Manager or Parameter Store.
Implement pod-level identities.
Integrate the Secrets Store CSI Driver.
Encrypt storage.
Define KMS governance.
Implement secret rotation.
Monitor access.

Phase 10 — Implement Detection and Response

Enable EKS control plane logs.
Centralise Kubernetes audit logs.
Enable GuardDuty and security services.
Deploy runtime monitoring.
Integrate findings with Security Hub.
Forward critical telemetry to the SIEM.
Create EKS incident runbooks.
Test containment procedures.

Phase 11 — Implement Recovery

Define workload RPO and RTO.
Protect Kubernetes resources.
Protect persistent data.
Implement immutable backups.
Copy critical backups across accounts and Regions.
Rebuild infrastructure through code.
Test restoration.
Conduct disaster-recovery exercises.

Phase 12 — Continuous Validation

Scan clusters continuously.
Monitor drift.
Review access.
Review exceptions.
Test alerts.
Measure remediation SLAs.
Conduct penetration tests.
Conduct incident simulations.
Update architecture standards.

Enterprise Best Practices

As a Cloud Security Engineer:

Use AWS accounts and clusters as deliberate isolation boundaries.
Separate production and non-production workloads.
Create a reusable secure EKS landing zone.
Manage cluster infrastructure through code.
Use federated identities, MFA and temporary credentials.
Manage cluster access with EKS access entries.
Apply least-privilege Kubernetes RBAC.
Use just-in-time administrative access.
Use dedicated Kubernetes Service Accounts.
Use EKS Pod Identity or IRSA for AWS permissions.
Run production worker nodes in private subnets.
Restrict the EKS API endpoint.
Apply least-privilege Security Groups.
Implement default-deny Network Policies.
Control ingress and egress paths.
Use approved, hardened and replaceable worker-node images.
Apply Restricted Pod Security standards.
Deny privileged and host-level workload access by default.
Enforce enterprise admission policies.
Secure Git, CI/CD and deployment roles.
Scan, sign and verify container images.
Generate and retain SBOMs.
Store secrets in approved external services.
Encrypt data, logs, backups and storage.
Enable EKS control plane and Kubernetes audit logging.
Integrate runtime findings with the SOC.
Monitor the security-monitoring pipeline itself.
Build tested incident-response runbooks.
Use encrypted, immutable and cross-region backups.
Test restoration and disaster recovery.
Automate compliance evidence.
Track security metrics and remediation SLAs.
Require documented and time-limited exceptions.
Continuously review and improve the architecture.

Real-World Scenario

A multinational financial organisation operates more than 400 Amazon EKS clusters across multiple AWS accounts and Regions.

The clusters support:

Digital banking
Payment processing
Customer identity
Fraud detection
Regulatory reporting
Internal analytics

The existing environment has grown independently across business units.

A security assessment identifies:

Production and development clusters in the same accounts
Public EKS API endpoints
Shared administrator roles
Permanent cluster-admin access
Broad worker-node IAM permissions
Inconsistent Network Policies
Privileged workloads
Unsigned container images
Secrets stored in CI/CD variables
Inconsistent audit logging
Runtime alerts not integrated with the SOC
Backups stored only in the primary account
Security exceptions without expiry dates

The organisation launches an enterprise EKS security-transformation programme.

The Cloud Security, Platform Engineering and SOC teams:

Establish a multi-account AWS organisation model.
Create dedicated security-tooling and log-archive accounts.
Separate production, non-production and regulated workloads.
Develop an approved Terraform-based EKS landing zone.
Restrict production clusters to approved Regions.
Move administrative access to IAM Identity Center.
Require MFA and temporary credentials.
Implement EKS access entries.
Remove permanent cluster-admin assignments.
Introduce time-limited privileged access.
Move production nodes to private subnets.
Restrict EKS API endpoint access.
Implement default-deny Network Policies.
Deploy VPC endpoints and controlled egress.
Standardise managed node groups using approved images.
Enforce IMDSv2 and encrypted EBS volumes.
Apply Restricted Pod Security Admission.
Deploy enterprise admission policies.
Implement EKS Pod Identity for applications.
Move secrets into AWS Secrets Manager.
Protect source repositories and CI/CD pipelines.
Require image scanning, SBOM generation and image signing.
Verify approved images during admission.
Enable all required control plane logs.
Centralise audit and runtime telemetry.
Enable GuardDuty, Inspector and Security Hub aggregation.
Integrate security findings with the enterprise SIEM.
Create EKS-specific incident-response runbooks.
Implement immutable cross-account backups.
Conduct multi-region disaster-recovery testing.
Build automated compliance dashboards.
Introduce time-limited security exceptions.
Conduct quarterly architecture and access reviews.

The organisation achieves:

Reduced blast radius
Consistent multi-cluster security
Stronger identity governance
Improved workload isolation
Better software-supply-chain protection
Faster threat detection
Central incident-response visibility
Improved audit evidence
Tested recovery capability
Clear accountability across teams

Key Takeaways

Enterprise EKS security requires an integrated architecture rather than isolated tools.
AWS accounts and EKS clusters provide important isolation boundaries.
A secure EKS landing zone creates repeatable security controls.
Human access should use federation, MFA and temporary credentials.
EKS access entries and Kubernetes RBAC provide complementary access controls.
Workloads should use dedicated Service Accounts and pod-level IAM identities.
Production worker nodes should be private, hardened and replaceable.
Network security requires both AWS controls and Kubernetes Network Policies.
Pod Security Admission and policy engines enforce secure workload configurations.
Secure software delivery requires scanning, SBOMs, signing and verification.
Secrets should be managed externally and accessed through least-privilege identities.
Runtime security detects attacks after workloads begin running.
CloudTrail, EKS audit logs and runtime telemetry provide complementary visibility.
Security findings must integrate with SOC response processes.
Infrastructure as Code, GitOps and Policy as Code reduce configuration drift.
Backup, incident response and disaster recovery are core security architecture components.
Compliance should be continuously measured.
Exceptions must be approved, monitored and time-limited.

Knowledge Check

1. Why should enterprises use multiple AWS accounts for EKS environments?

Answer: Multiple accounts create strong isolation boundaries, reduce blast radius, separate environments, simplify compliance scoping and support independent administrative and billing controls.

2. What is the role of an enterprise EKS landing zone?

Answer: An EKS landing zone provides approved, reusable infrastructure, security controls, add-ons, logging, network configurations and governance processes for consistently deploying secure clusters.

3. Why should applications use EKS Pod Identity or IRSA?

Answer: They provide temporary, least-privilege AWS credentials to individual workloads and prevent applications from relying on broad worker-node IAM roles or static access keys.

4. How do preventive and detective controls work together?

Answer: Preventive controls such as admission policies and Network Policies block unsafe activity, while detective controls such as audit logging and runtime monitoring identify suspicious actions that bypass or occur after preventive controls.

5. Why are Infrastructure as Code and Policy as Code important?

Answer: They make security configurations repeatable, reviewable, testable and auditable while reducing manual errors and configuration drift.

What’s Next?

You have now completed the core Amazon EKS Security Architecture lessons.

The next step is to apply these concepts through a practical enterprise lab in which you will assess, harden and validate an Amazon EKS environment.

➡️ Next: Lab — Build and Secure an Enterprise Amazon EKS Cluster