Lesson 05 — Amazon EKS Cluster Hardening

Learning Objectives

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

Explain the purpose of Amazon EKS cluster hardening
Identify the major attack surfaces in an EKS environment
Secure the EKS control plane and Kubernetes API
Harden worker nodes and node groups
Apply secure workload defaults
Protect cluster add-ons and platform components
Reduce privilege-escalation opportunities
Apply defence-in-depth across identity, network and runtime layers
Build a standard enterprise EKS hardening baseline
Validate and continuously monitor cluster hardening
Design a practical Amazon EKS hardening roadmap

Why This Matters

An Amazon EKS cluster can be operational without being secure.

Default or poorly governed configurations may expose the environment to:

Excessive administrator access
Public Kubernetes API exposure
Privileged workloads
Broad node IAM permissions
Weak network isolation
Unencrypted data
Insecure container images
Missing audit logs
Outdated nodes and add-ons
Uncontrolled configuration changes

Cluster hardening reduces the attack surface before an attacker gains access.

Default Cluster

↓

Security Baseline

↓

Reduced Attack Surface

↓

Continuous Validation

↓

Hardened Amazon EKS Environment

For a Cloud Security Engineer, hardening is the process of turning a functional EKS cluster into a production-ready security platform.

What is Cluster Hardening?

Cluster hardening is the process of reducing unnecessary exposure, restricting privileges and enforcing secure configurations across the Kubernetes environment.

Hardening applies to:

AWS account
EKS control plane
Kubernetes API
IAM
RBAC
Worker nodes
Pod security
Networking
Storage
Secrets
Container images
Add-ons
Logging
Monitoring
Operations

Amazon EKS Attack Surface

Amazon EKS Attack Surface

├── AWS IAM
├── EKS API Endpoint
├── Kubernetes API
├── EKS Access Entries
├── Kubernetes RBAC
├── Worker Nodes
├── Pods and Containers
├── Service Accounts
├── Container Images
├── Network Paths
├── Secrets
├── Add-ons
├── CI/CD Pipelines
└── Logging and Monitoring Systems

Every exposed or misconfigured component may become an entry point.

Hardening Principles

A mature EKS hardening programme should follow these principles:

Least Privilege

+

Secure by Default

+

Defence in Depth

+

Automation

+

Continuous Verification

Shared Responsibility for Hardening

AWS manages the EKS managed control plane infrastructure.

The customer remains responsible for hardening:

Cluster configuration
API access
IAM
EKS access entries
Kubernetes RBAC
Worker nodes
Workloads
Network controls
Secrets
Images
Logging
Monitoring
Compliance

AWS Secures the Managed Service

Customer Secures the Cluster Usage

Hardening Layers

Layer 1 — AWS Account and IAM

↓

Layer 2 — EKS Control Plane Access

↓

Layer 3 — Kubernetes Authorization

↓

Layer 4 — Worker Nodes

↓

Layer 5 — Workloads

↓

Layer 6 — Networking and Data

↓

Layer 7 — Monitoring and Response

A hardened cluster requires controls at every layer.

Harden the AWS Account

The AWS account hosting Amazon EKS should follow enterprise security standards.

Apply:

AWS Organizations
Service Control Policies
Central logging
MFA
IAM Identity Center
Short-lived credentials
Restricted administrative roles
AWS Config
CloudTrail
GuardDuty
Security Hub
Account-level tagging

Separate Production and Non-Production

Production clusters should not share the same AWS account with development environments where possible.

Development Account

↓

Development EKS Cluster

Production Account

↓

Production EKS Cluster

This reduces:

Blast radius
Privilege overlap
Accidental changes
Compliance complexity
Service quota contention

Protect the EKS API Endpoint

The EKS API endpoint is the entry point to cluster administration.

Options include:

Public endpoint
Private endpoint
Public and private endpoints

For sensitive clusters, prefer private access where operationally feasible.

Private API Architecture

Administrator

↓

Corporate Network

↓

VPN or Direct Connect

↓

Private VPC Access

↓

Amazon EKS API Endpoint

Restricted Public Access

If public endpoint access is required:

Restrict permitted CIDR ranges.
Require strong IAM authentication.
Require MFA.
Use temporary credentials.
Monitor access attempts.
Remove broad internet access.

Avoid:

0.0.0.0/0

for production API endpoint access.

Enable EKS Control Plane Logging

Enable appropriate control plane logs:

API Server
Audit
Authenticator
Controller Manager
Scheduler

Amazon EKS Control Plane

↓

CloudWatch Logs

↓

Central Log Archive

↓

SIEM

↓

SOC

These logs support:

Incident response
Privileged activity monitoring
Compliance
Troubleshooting
Access reviews

Protect Audit Logs

Audit logs should be:

Centralised
Encrypted
Access-controlled
Retained
Monitored
Protected from deletion
Integrated with SIEM alerts

High-risk events include:

ClusterRoleBinding creation
Secret access
Pod execution
Privileged Pod creation
Admission webhook changes
Namespace deletion
Service Account token creation

Harden Authentication

Human administrators should use:

Enterprise federation
AWS IAM Identity Center
MFA
Temporary AWS STS credentials
Role-based access
Session expiry
Central access reviews

Avoid:

Shared administrator accounts
Long-lived access keys
Static Kubernetes credentials
Permanent unrestricted access

Use EKS Access Entries

Use EKS Access Entries for AWS-native cluster-access management.

Benefits include:

API-based administration
Better CloudTrail visibility
Reduced manual configuration
Central access lifecycle
Easier automation

Legacy aws-auth mappings should be reviewed and reduced where modern access entries are adopted.

Restrict Cluster-Admin

cluster-admin provides unrestricted cluster access.

Review:

kubectl get clusterrolebindings

Identify:

Human users
IAM roles
Groups
Service Accounts

that receive broad privileges.

Privileged Access Model

Normal Access

↓

Namespace-Scoped Permissions

Temporary Administrative Need

↓

Approved Privileged Role

↓

Time-Limited Access

↓

Access Removed

↓

Post-Access Review

Apply Least-Privilege RBAC

Prefer namespace-scoped Roles.

Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-reader
  namespace: payments

rules:
  - apiGroups:
      - apps

    resources:
      - deployments

    verbs:
      - get
      - list
      - watch

Avoid wildcard permissions unless clearly justified.

High-Risk RBAC Permissions

Review permissions to:

Read Secrets
Create Pods
Execute into Pods
Create RoleBindings
Create ClusterRoleBindings
Modify webhooks
Create Service Account tokens
Impersonate users or groups
Modify Nodes
Modify security policies

A user who can create Pods may be able to escalate privileges depending on workload restrictions.

Separate Human and Workload Identity

Human identities should use IAM federation.

Workloads should use:

Dedicated Service Accounts
EKS Pod Identity
IRSA
Least-privilege IAM roles

Human

↓

Federated IAM Role

Workload

↓

Service Account

↓

Pod-Level IAM Role

Do not use broad node roles for application permissions.

Harden Service Accounts

Apply:

Dedicated Service Account per workload
Minimum Kubernetes API permissions
Minimum AWS IAM permissions
Disable unnecessary token mounting
Regular reviews
Namespace-scoped use

Example:

spec:
  automountServiceAccountToken: false

Protect Worker Nodes

Worker nodes run the actual application containers.

Hardening should include:

Approved EKS-optimised AMIs
Managed Node Groups where appropriate
Regular patching
Automated replacement
Encrypted storage
IMDSv2
Restricted Security Groups
No public IP addresses
Restricted SSH
Minimal software
Host monitoring

Use Private Subnets

Production worker nodes should generally run in private subnets.

Internet

↓

Public Load Balancer

↓

Private Worker Nodes

↓

Application Pods

Benefits include:

Reduced direct exposure
Controlled egress
Simplified security boundaries
Smaller attack surface

Restrict SSH Access

Avoid direct SSH access where possible.

Prefer:

AWS Systems Manager
Automated diagnostics
Immutable node replacement
Approved break-glass procedures

If SSH is required:

Restrict source networks.
Use temporary access.
Log sessions.
Remove access after use.

Immutable Node Management

Treat worker nodes as replaceable infrastructure.

Updated AMI

↓

New Node Group

↓

Workloads Rescheduled

↓

Old Nodes Drained

↓

Old Node Group Deleted

Avoid long-lived, manually modified servers.

Use Approved AMIs

Use:

EKS-optimised AMIs
Approved Bottlerocket images
Enterprise-approved hardened images
Signed and controlled image pipelines

Custom AMIs should have:

Documented build process
Security scanning
Patch lifecycle
Version control
Testing
Rollback plan

Bottlerocket

Bottlerocket is a container-focused operating system designed for running containers.

Potential benefits include:

Reduced package surface
Transactional updates
Minimal host environment
Stronger immutability
Reduced administrative exposure

It may require different operational procedures than traditional Linux nodes.

Enforce IMDSv2

Instance Metadata Service Version 2 improves protection against credential theft.

Use:

IMDSv2
Restricted metadata hop limits
Pod-level AWS identities
Restricted node IAM roles

Application Pod

Should Use

EKS Pod Identity or IRSA

Not

Broad Node Credentials

Restrict Node IAM Roles

Node IAM roles should include only node-level requirements.

Applications should not depend on node roles for access to:

S3
DynamoDB
Secrets Manager
KMS
SQS
Other application services

Broad node roles increase the impact of Pod compromise.

Encrypt Node Storage

Encrypt:

Root EBS volumes
Data volumes
Persistent storage
Snapshots

Use approved AWS KMS keys where required.

Apply Node Isolation

Separate workloads using dedicated node groups.

Amazon EKS Cluster

├── System Node Group
├── Application Node Group
├── Security Tooling Node Group
├── Sensitive Workload Node Group
└── Legacy Exception Node Group

Use:

Taints
Tolerations
Node selectors
Affinity
Dedicated IAM roles
Dedicated Security Groups

Protect System Components

System workloads may include:

CoreDNS
VPC CNI
kube-proxy
CSI drivers
Ingress controllers
Admission controllers
GitOps controllers
Monitoring agents
Runtime security tools

These components often have elevated privileges.

They should be:

Owned
Version-controlled
Monitored
Patched
Protected by RBAC
Deployed with high availability
Reviewed regularly

Harden the Amazon VPC CNI

The VPC CNI has permissions to manage networking.

Protect it through:

Dedicated IAM role
Least privilege
Managed add-on lifecycle
Restricted RBAC
Controlled configuration
Monitoring
Change alerts
Approved upgrade process

Harden CoreDNS

CoreDNS is critical to service discovery.

Apply:

Multiple replicas
Resource requests and limits
PodDisruptionBudget
Multi-AZ placement
Restricted RBAC
Configuration review
Monitoring
Controlled upgrades

Harden kube-proxy

Protect kube-proxy through:

Managed version control
Restricted permissions
Standardised configuration
Upgrade compatibility testing
Monitoring

Changes to kube-proxy may affect cluster-wide service networking.

Secure Add-On Lifecycle

For every add-on, document:

Attribute	Required Information
Owner	Responsible platform team
Version	Approved version
Source	Approved repository
IAM permissions	Least-privilege role
RBAC permissions	Reviewed roles
Upgrade schedule	Defined lifecycle
Monitoring	Metrics and alerts
Recovery	Rollback procedure

Apply Pod Security Admission

Use Pod Security Admission to enforce secure Pod configurations.

Recommended production target:

Restricted

Rollout path:

Warn

↓

Audit

↓

Remediation

↓

Enforce

Namespace Pod Security Labels

Example:

kubectl label namespace payments \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted

Validate compatibility before enforcement.

Deny Privileged Containers

Unsafe configuration:

securityContext:
  privileged: true

Privileged Pods can gain extensive access to the worker node.

They should be blocked by default.

Approved exceptions should be:

Narrow
Documented
Time-limited
Isolated
Monitored

Run Containers as Non-Root

securityContext:
  runAsNonRoot: true
  runAsUser: 10001

The image must support non-root execution.

Disable Privilege Escalation

securityContext:
  allowPrivilegeEscalation: false

This reduces the ability of a process to gain additional privileges.

Drop Linux Capabilities

securityContext:
  capabilities:
    drop:
      - ALL

Add only the minimum capabilities required.

Use Read-Only Root Filesystems

securityContext:
  readOnlyRootFilesystem: true

Use dedicated writable volumes for temporary data.

Apply Seccomp

securityContext:
  seccompProfile:
    type: RuntimeDefault

Seccomp restricts available Linux system calls.

Restrict Host Namespaces

Block or tightly restrict:

hostNetwork: true
hostPID: true
hostIPC: true

These settings reduce isolation between the Pod and the worker node.

Restrict HostPath

HostPath mounts provide access to the node filesystem.

Unsafe example:

volumes:
  - name: host-root

    hostPath:
      path: /

HostPath should be denied unless required by approved platform tooling.

Restrict Host Ports

Host ports may expose services directly through worker nodes.

Risks include:

Port conflicts
Expanded attack surface
Bypassing approved ingress
Reduced scheduling flexibility

Use Kubernetes Services and approved ingress paths where possible.

Require Resource Requests and Limits

resources:
  requests:
    cpu: 100m
    memory: 128Mi

  limits:
    cpu: 500m
    memory: 512Mi

Benefits include:

Reduced resource exhaustion
Better scheduling
Predictable performance
Improved availability
Reduced noisy-neighbour risk

Secure Workload 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-sa
      automountServiceAccountToken: false

      securityContext:
        runAsNonRoot: true

        seccompProfile:
          type: RuntimeDefault

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

          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true

            capabilities:
              drop:
                - ALL

          resources:
            requests:
              cpu: 100m
              memory: 128Mi

            limits:
              cpu: 500m
              memory: 512Mi

Enforce Admission Policies

Use admission policies to reject insecure resources.

High-value policies include:

Deny privileged containers
Require non-root
Require read-only filesystems
Drop capabilities
Restrict HostPath
Restrict host namespaces
Require resource limits
Restrict image registries
Deny latest tags
Require ownership labels
Restrict LoadBalancer Services
Restrict Service Account token mounting

Admission Policy Layers

Pod Security Admission

↓

Kyverno, Gatekeeper or Native Policies

↓

Custom Enterprise Controls

Use Audit Before Enforce

Policy Created

↓

CI/CD Testing

↓

Audit Mode

↓

Violations Reviewed

↓

Applications Remediated

↓

Enforcement Enabled

This reduces unexpected production disruption.

Protect Admission Controllers

Admission controllers are high-value security components.

Protect them with:

Restricted RBAC
Multiple replicas
PodDisruptionBudgets
Dedicated namespaces
Resource limits
Certificate monitoring
GitOps
Change alerts
Health monitoring

Failure Policy

Webhook failure behaviour may be configured as:

Fail Open
Fail Closed

Option	Benefit	Risk
Fail Open	Preserves availability	May permit insecure deployments
Fail Closed	Preserves enforcement	May block cluster operations

The decision should be risk-based.

Harden Network Access

Apply:

Private worker nodes
Restricted EKS API endpoint
Least-privilege Security Groups
Default-deny Network Policies
Controlled ingress
Controlled egress
VPC endpoints
Flow logging
DNS monitoring

Default-Deny Network Policy

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

spec:
  podSelector: {}

  policyTypes:
    - Ingress
    - Egress

Required flows should then be explicitly allowed.

Restrict Public Exposure

Control:

LoadBalancer Services
Ingress resources
Public load balancers
NodePort Services
Host ports
External IPs

Use admission policies to prevent unapproved exposure.

Harden Ingress

Require:

TLS
Approved IngressClass
AWS WAF where required
Approved certificates
Restricted hostnames
Access logging
Rate limiting
Authentication
Secure headers

Control Egress

Use:

Network Policies
Security Groups
NAT controls
VPC endpoints
Central firewalls
Egress proxies
DNS filtering
Monitoring

Unrestricted egress increases data-exfiltration risk.

Protect DNS

Apply:

CoreDNS monitoring
Restricted configuration changes
Multiple replicas
Resource controls
DNS telemetry
Alerts for unusual queries
Approved resolvers

Encrypt Kubernetes Secrets

Enable EKS encryption configuration using AWS KMS where required.

Kubernetes Secret

↓

EKS Encryption Provider

↓

AWS KMS

↓

Encrypted Data Storage

Use External Secrets Management

For sensitive applications, consider:

AWS Secrets Manager
Systems Manager Parameter Store
Secrets Store CSI Driver
External Secrets Operator

Avoid plaintext Secrets in:

Git
Container images
ConfigMaps
CI/CD logs
Documentation

Restrict Secret Access

Review identities that can:

Get Secrets
List Secrets
Watch Secrets
Create Pods that mount Secrets
Execute into Pods
Create Service Account tokens

Secret access can occur directly or indirectly.

Harden Container Images

Require production images to be:

Stored in approved registries
Scanned
Signed
Deployed by immutable digest
Built from approved base images
Accompanied by SBOMs
Free from unresolved critical findings

Avoid Mutable Tags

Avoid:

image: payment-api:latest

Prefer:

image: payment-api@sha256:exampledigest

Scan Images Continuously

Scan:

During development
During build
When pushed to Amazon ECR
Before deployment
After new vulnerabilities are discovered
While images remain deployed

Sign and Verify Images

Approved Pipeline

↓

Build

↓

Scan

↓

Sign

↓

Push to Amazon ECR

↓

Verify During Admission

↓

Deploy

Protect CI/CD

Restrict:

Source repositories
Branches
Build runners
Pipeline credentials
Deployment roles
Signing keys
GitOps controllers

Require:

Peer review
Security tests
Protected branches
Short-lived credentials
Least-privilege deployment roles

Use Infrastructure as Code

Manage through code:

VPC
EKS cluster
Node groups
Security Groups
IAM roles
Logging
Encryption
Add-ons

Benefits include:

Repeatability
Review
Audit history
Drift detection
Recovery

Use GitOps

Manage Kubernetes state through approved repositories.

Pull Request

↓

Review

↓

Security Validation

↓

Approval

↓

GitOps Controller

↓

Amazon EKS

Restrict direct production changes.

Detect Configuration Drift

Compare:

Approved Configuration

with

Actual Cluster State

Drift may affect:

RBAC
Network Policies
Admission policies
Add-ons
Namespace labels
Workloads
Logging configuration

Patch and Upgrade Regularly

Track:

Kubernetes version
Managed add-ons
Node AMIs
Container runtime
CoreDNS
VPC CNI
kube-proxy
CSI drivers
Admission controllers
Ingress controllers

Upgrade Sequence

Development

↓

Testing

↓

Staging

↓

Production

Validate:

API compatibility
Policy compatibility
Add-on versions
Application behaviour
Security monitoring

Vulnerability Management

Cover:

Worker nodes
Container images
Application dependencies
Add-ons
Helm charts
CI/CD tooling
Base images
Runtime packages

Vulnerability Prioritisation

Consider:

Severity
Exploitability
Internet exposure
Runtime usage
Business criticality
Data classification
Compensating controls

Runtime Security

Configuration hardening cannot detect all runtime attacks.

Monitor for:

Shell execution
Unexpected processes
Privilege escalation
Sensitive file access
Cryptomining
Malware
Container escape behaviour
Unusual outbound connections

Tools such as Falco may provide runtime detection.

Central Security Monitoring

EKS Audit Logs

+

CloudTrail

+

GuardDuty

+

Inspector

+

Admission Events

+

Runtime Alerts

↓

Enterprise SIEM

↓

SOC

Monitor Cluster Hardening

Monitor:

Public API exposure
Cluster-admin assignments
RBAC changes
Unapproved privileged workloads
Missing Pod Security labels
Admission policy failures
Broad Security Group rules
Missing Network Policies
Vulnerabilities
Unsupported versions
Logging failures
Expired exceptions

Hardening Metrics

Metric	Target
Production clusters using approved baseline	100%
Clusters with control plane logging	100%
Unapproved cluster-admin bindings	0
Production namespaces using Restricted PSA	100%
Unapproved privileged workloads	0
Critical vulnerabilities beyond SLA	0
Worker nodes in private subnets	100%
Images from approved registries	100%
Unsupported EKS versions	0
Expired hardening exceptions	0

Validate Hardening

Validation may include:

CIS Kubernetes Benchmark
kube-bench
Policy reports
AWS Config
Security Hub
Inspector
Manual architecture reviews
Penetration testing
Incident simulations
Configuration comparison

Example Validation Commands

kubectl auth can-i --list

kubectl get clusterrolebindings

kubectl get namespaces --show-labels

kubectl get networkpolicies -A

kubectl get pods -A -o yaml

aws eks describe-cluster \
  --name production-eks

Hardening Assessment Areas

Area	Validation Questions
API	Is access private or restricted?
Identity	Is MFA and federation enforced?
RBAC	Is least privilege applied?
Nodes	Are nodes private and patched?
Pods	Are restricted security settings enforced?
Network	Is default-deny applied?
Images	Are images approved and scanned?
Secrets	Are Secrets encrypted and restricted?
Logging	Are audit logs centralised?
Monitoring	Are runtime and control alerts active?

Exception Management

Some workloads may not immediately meet the hardening baseline.

Every exception should include:

Control:

Cluster:

Namespace:

Workload:

Business Justification:

Risk:

Compensating Controls:

Owner:

Approver:

Expiry Date:

Remediation Plan:

Exceptions should never be permanent by default.

Cluster Hardening Baseline

A production baseline may include:

Security Domain	Required Control
API Access	Private or restricted endpoint
Human Identity	Federation, MFA and temporary credentials
Cluster Access	EKS Access Entries
RBAC	Least privilege
Nodes	Private, patched and encrypted
Workloads	Restricted Pod security
Network	Default-deny and controlled ingress/egress
Images	Approved, scanned, signed and immutable
Secrets	KMS and external secret management
Logging	Control plane and audit logs
Monitoring	Runtime detection and SIEM
Governance	GitOps, evidence and exceptions

Common Hardening Failures

Public API Without Restrictions

Risk: Increased control-plane exposure.

Control: Use private access or approved CIDR restrictions.

Permanent Cluster-Admin

Risk: Credential compromise provides complete control.

Control: Use time-limited privileged access.

Broad Node IAM Role

Risk: Compromised Pods access excessive AWS permissions.

Control: Use EKS Pod Identity or IRSA.

Privileged Containers

Risk: Workloads may compromise nodes.

Control: Enforce Pod Security Admission and admission policies.

No Network Segmentation

Risk: Attackers move laterally between workloads.

Control: Apply default-deny Network Policies.

Mutable Images

Risk: Unapproved content reaches production.

Control: Use immutable digests and signature verification.

Missing Audit Logs

Risk: Incidents cannot be reconstructed.

Control: Enable and centralise EKS control plane logging.

Manual Node Changes

Risk: Configuration drift and inconsistent patching.

Control: Replace nodes through approved images and automation.

Permanent Exceptions

Risk: Known control gaps remain unresolved.

Control: Require expiry dates and remediation plans.

Enterprise Hardening Architecture

Enterprise Identity Provider

↓

AWS IAM Federation and MFA

↓

Restricted EKS API Endpoint

↓

EKS Access Entries

↓

Least-Privilege Kubernetes RBAC

↓

Pod Security Admission

↓

Kyverno or Gatekeeper

↓

Hardened Workloads

↓

Private Worker Nodes

↓

Default-Deny Network Policies

↓

Encrypted Secrets and Storage

↓

Approved Signed Images

↓

Runtime Monitoring and Audit Logs

↓

Central SIEM and Compliance Reporting

Enterprise Implementation Strategy

Phase 1 — Assess Current State

Inventory clusters.
Identify owners.
Review API endpoint exposure.
Review IAM and RBAC.
Review node groups.
Review workload security.
Review network controls.
Review logging and monitoring.

Phase 2 — Define the Hardening Baseline

Select applicable CIS controls.
Define required EKS settings.
Define Pod security requirements.
Define network requirements.
Define image-security requirements.
Define exception criteria.

Phase 3 — Harden Identity and API Access

Implement federation and MFA.
Use EKS Access Entries.
Restrict cluster-admin.
Apply least-privilege RBAC.
Restrict public API access.
Enable audit logging.

Phase 4 — Harden Worker Nodes

Move nodes to private subnets.
Use approved AMIs.
Enforce IMDSv2.
Encrypt storage.
Restrict node IAM roles.
Implement immutable replacement.
Separate sensitive node groups.

Phase 5 — Harden Workloads

Apply Pod Security Admission.
Require non-root.
Disable privilege escalation.
Drop capabilities.
Apply seccomp.
Restrict HostPath.
Require resource controls.

Phase 6 — Harden Network and Data

Apply default-deny Network Policies.
Restrict ingress and egress.
Use VPC endpoints.
Encrypt Secrets.
Integrate external secret management.
Restrict database access.

Phase 7 — Secure the Supply Chain

Use approved ECR repositories.
Scan images.
Generate SBOMs.
Sign images.
Verify images during admission.
Protect CI/CD.

Phase 8 — Automate and Govern

Use Infrastructure as Code.
Store policies in Git.
Apply GitOps.
Detect drift.
Track exceptions.
Automate compliance evidence.

Phase 9 — Monitor and Respond

Centralise logs.
Deploy runtime detection.
Create SIEM alerts.
Monitor security tooling.
Create EKS incident runbooks.
Test containment actions.

Phase 10 — Validate and Improve

Run regular assessments.
Track hardening metrics.
Retest failed controls.
Review exceptions.
Update the baseline.
Test disaster recovery.
Conduct security exercises.

Enterprise Best Practices

As a Cloud Security Engineer:

Use a documented hardening baseline for every production cluster.
Restrict the EKS API endpoint.
Require federation, MFA and temporary credentials.
Use EKS Access Entries and least-privilege RBAC.
Restrict permanent cluster-admin access.
Run worker nodes in private subnets.
Use approved, patched and encrypted node images.
Enforce IMDSv2.
Use pod-level AWS identities.
Apply Restricted Pod Security standards.
Deny privileged and host-level workloads by default.
Require non-root, seccomp and read-only filesystems.
Apply default-deny Network Policies.
Restrict public exposure and egress.
Encrypt Secrets and use external secret management.
Use scanned, signed and immutable images.
Protect add-ons and admission controllers.
Centralise audit logs and runtime alerts.
Use Infrastructure as Code and GitOps.
Monitor drift, exceptions and control effectiveness.
Validate hardening continuously rather than only during audits.

Real-World Scenario

A global financial organisation runs over 200 Amazon EKS clusters supporting customer applications, internal systems and payment services.

A security assessment identifies:

Public EKS API endpoints open to broad networks
Permanent cluster-admin assignments
Broad worker-node IAM roles
Worker nodes with outdated AMIs
Privileged Pods
Missing Pod Security Admission
No default-deny Network Policies
Mutable container image tags
Inconsistent control plane logging
Permanent security exceptions

The organisation launches an EKS hardening programme.

The Platform and Cloud Security teams:

Create an approved enterprise EKS baseline.
Move production API access to private endpoints.
Integrate IAM Identity Center with MFA.
Replace broad mappings with EKS Access Entries.
Remove permanent cluster-admin access.
Introduce time-limited privileged roles.
Migrate worker nodes to private subnets.
Replace outdated node groups using approved AMIs.
Enforce IMDSv2 and encrypted storage.
Implement EKS Pod Identity for applications.
Apply Restricted Pod Security Admission.
Deploy Kyverno policies for enterprise controls.
Block privileged Pods and HostPath mounts.
Apply default-deny Network Policies.
Restrict public load balancer creation.
Require signed, scanned and digest-pinned images.
Enable all required control plane logs.
Deploy runtime monitoring and SIEM integration.
Create time-limited exception workflows.
Automate hardening validation across every cluster.

The result is:

Reduced attack surface
Improved least privilege
Stronger workload isolation
Better visibility
Faster compliance reporting
Consistent multi-cluster security
Reduced configuration drift

Key Takeaways

Cluster hardening reduces the Amazon EKS attack surface.
Hardening must cover AWS, Kubernetes, nodes, workloads, networks and operations.
Private and restricted API access reduces control-plane exposure.
Federation, MFA and temporary credentials strengthen administrative access.
Least-privilege RBAC limits the impact of compromised identities.
Worker nodes should be private, patched, encrypted and replaceable.
Pod-level identities are safer than broad node IAM roles.
Restricted Pod security should be enforced in production.
Default-deny networking reduces lateral movement.
Container images should be approved, scanned, signed and immutable.
Audit logs and runtime monitoring are essential for detection and response.
Infrastructure as Code and GitOps reduce configuration drift.
Hardening controls should be continuously validated.
Exceptions must be narrow, approved and time-limited.

Knowledge Check

1. What is the purpose of Amazon EKS cluster hardening?

Answer: Cluster hardening reduces the attack surface by removing unnecessary exposure, restricting privileges, enforcing secure configurations and continuously validating security controls.

2. Why should worker nodes run in private subnets?

Answer: Private subnets reduce direct internet exposure and provide better control over inbound and outbound traffic.

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

Answer: They provide least-privilege AWS credentials to individual workloads and reduce dependency on broad worker-node IAM roles.

4. What is the purpose of Pod Security Admission?

Answer: Pod Security Admission enforces Kubernetes Pod security standards and helps block insecure workload configurations such as privileged containers or excessive host access.

5. Why should cluster hardening be continuously validated?

Answer: Configurations can drift, software can become outdated, exceptions can expire and new vulnerabilities can emerge. Continuous validation ensures controls remain effective.

What’s Next?

In the next lesson, we will explore Amazon EKS Secrets Management, including Kubernetes Secrets, AWS KMS encryption, AWS Secrets Manager, Systems Manager Parameter Store, CSI integrations, access control and secret-rotation strategies.

➡️ Next Lesson: Lesson 06 — Secrets Management