Amazon EKS Security Review
Get the IAM mapping wrong and Kubernetes RBAC never even sees the request that just became cluster-admin. We test the access entries, aws-auth bindings, IRSA and Pod Identity roles behind it. CREST-certified testers, fixed price from £3,740 for a 3-day single-cluster scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Every EKS cluster maps AWS IAM identities to Kubernetes permissions through access entries or the legacy aws-auth ConfigMap, and the cluster creator keeps a permanent admin binding by default. We test who that mapping actually lets in.
Why EKS security depends on how IAM maps to Kubernetes
Every EKS cluster grants Kubernetes API access through access entries or the older aws-auth ConfigMap, and the IAM identity that created the cluster keeps a permanent cluster-admin binding by default unless that binding is explicitly removed. Turning on access entries on an older cluster only recreates the entry for that original creator automatically; any other role or user someone added to the ConfigMap by hand has to be re-added by hand. We map every access entry and ConfigMap binding against the Kubernetes RBAC it actually resolves to, and flag whichever cluster-admin binding from creation day nobody has reviewed since.
Two mechanisms let a pod call AWS services under its own IAM role: IAM roles for service accounts (IRSA), which use the cluster’s OIDC provider, and the newer EKS Pod Identity, which is not available to pods running on Fargate or Windows nodes. Neither one stops a pod inheriting the node’s own IAM role through the EC2 instance metadata service unless that access is separately restricted, so a workload with no identity of its own can still pick up whatever the node role allows. We test which mechanism is actually wired to each service account, whether an IRSA trust policy is scoped to a single namespace and service account rather than the whole namespace, and whether IMDS is reachable from pods that should not have it.
Your EKS cluster’s API server can be public, public with a CIDR allow-list, or private inside your VPC, and a new cluster defaults to a public endpoint with no CIDR restriction at all. AWS’s own EKS security best practices treat the control plane itself, the API server nodes and etcd, as AWS-managed infrastructure you never touch directly, which is also why AWS does not name EKS among the services its customer testing policy lists as approved. Your side of that boundary is the endpoint configuration, the identities that reach it and the workloads running behind it, and that is what we test.
SCOPE
What we review in an EKS cluster
IAM-to-Cluster Access Mapping
EKS grants Kubernetes API access through access entries or the legacy aws-auth ConfigMap, and enabling access entries on an existing cluster only recreates the entry for the original cluster creator automatically, any other role or user added to the ConfigMap by hand has to be re-added by hand. That original cluster creator also keeps a permanent cluster-admin binding by default unless it is explicitly removed. We map every access entry and ConfigMap binding against the Kubernetes RBAC it actually grants, and check whether the cluster-admin binding from creation is still sitting there unreviewed.
Kubernetes RBAC and Service Accounts
Access entries and IAM decide who reaches the API server; Kubernetes Roles, ClusterRoles and their bindings decide what they can do once inside, and a service account token mounted into a pod carries whatever that binding allows for as long as the pod runs. We test every Role and ClusterRole bound in the cluster for wildcard verbs or resources, over-broad bindings to the default service account, and the shortest chain from a single pod’s token to cluster-wide access.
IAM Roles for Service Accounts (IRSA)
IRSA lets a pod assume an IAM role through the cluster’s OIDC identity provider, but the role’s trust policy has to condition on the OIDC sub claim for a specific namespace and service account, not just the namespace, or every pod in that namespace can assume it. We test every IRSA trust policy against the exact service account it is meant to be scoped to.
EKS Pod Identity and Node Role Reachability
EKS Pod Identity is the newer alternative to IRSA, associated per service account and enforced by an agent running on each node, but it is not available to pods running on Fargate or Windows nodes. Whichever mechanism is used, a pod that has not been given its own identity can still inherit the node’s IAM role through the EC2 instance metadata service unless IMDS access is separately restricted. We test what each pod’s actual credential chain resolves to, including whether it falls back to the node role when it should not be able to.
API Server Endpoint Exposure
A new EKS cluster defaults to a public API server endpoint with no CIDR restriction, reachable from anywhere on the internet unless it is switched to private or given a public access CIDR list. Where both public and private access are enabled, traffic from inside your VPC uses the private path while the public endpoint stays open to whatever CIDR list is configured. We test the endpoint’s actual configuration against what your architecture assumes it is.
Pod Security Standards Enforcement
Kubernetes’ built-in Pod Security admission controller enforces the restricted, baseline or privileged Pod Security Standards per namespace through labels, and a namespace with no label set enforces nothing at all. We check which namespaces actually carry an enforce label, at which level, and test workloads for the privileged settings, such as hostNetwork, hostPath mounts or running as root, that the level in place should have blocked.
Network Policies Between Pods
The Amazon VPC CNI plugin can enforce Kubernetes NetworkPolicy objects, but only for pods on Amazon EC2 Linux nodes, not on Fargate or Windows nodes, and a standalone pod created without a controller behind it may not get policy enforcement applied reliably. Without a policy in place, every pod in the cluster can reach every other pod by default. We test what a compromised pod can actually reach across namespaces, and whether the policies you have written cover the workloads you think they cover.
Secrets Encryption with KMS
Clusters on Kubernetes 1.28 or later get envelope encryption for all Kubernetes API data by default, using an AWS-owned KMS key that lives outside your account and that you cannot manage directly, with the option to switch to a customer-managed key you do control. We check which key is actually protecting your cluster’s secrets and configuration data, and where a customer-managed key is in use, review its key policy and rotation.
Node Groups, Fargate and Add-on Versions
Managed node groups, self-managed nodes and Fargate shift how much of the security burden sits with AWS: Fargate removes node-level IMDS and network policy concerns entirely because pods do not share a node, while EC2-backed node groups keep both in scope. Add-ons such as the VPC CNI, CoreDNS and the Pod Identity agent run on whichever compute you choose and carry their own IAM permissions and version currency to check. Where your estate also runs Red Hat OpenShift, the same node and workload questions apply there under our OpenShift Penetration Testing.
Control Plane Logging and Audit Trail
EKS control plane logs, api, audit, authenticator, controllerManager and scheduler, are switched off by default and have to be enabled per log type before anything reaches CloudWatch. Without the audit log on, an access entry change or a suspicious session against the API server leaves nothing for your team to review afterwards. We check which log types are actually enabled and whether anything alerts on the ones that would show a permission change.
OUR PROCESS
Amazon EKS Security Review: From Scope to Attestation
Scope and Access
We agree the clusters, namespaces and AWS account boundary in scope, plus the kubeconfig or IAM access we need for each testing tier.
IAM and RBAC Mapping
We map every access entry or aws-auth binding, IRSA and Pod Identity association, and Kubernetes Role and ClusterRole against what it actually grants.
Manual Testing
A CREST-certified tester manually exploits weaknesses in identity mapping, RBAC, network policy and endpoint exposure, chaining findings toward cluster-wide access where they compound.
Reporting and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST EKS pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Amazon EKS Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test EKS For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Amazon EKS Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our EKS cluster?
At minimum, a read-only kubeconfig or an IAM identity with an access entry mapped to a cluster-viewer policy, plus an authenticated account for each distinct RBAC role or namespace tier you want tested. Where IRSA or EKS Pod Identity is in use, tell us which service accounts hold which IAM roles so we test the ones that actually matter.
Will testing touch our live data?
We test whichever environment you give us access to. If that is production, we agree exclusions upfront, such as node draining, workload restarts and any destructive kubectl actions, and do not run those against a live cluster without agreement in writing.
How long does an EKS cluster review take?
A single EKS cluster sits in our 3-day single-cluster scope, with a report typically landing around 5 working days after kickoff. Multiple clusters, a mixed node-group-and-Fargate estate or extensive IRSA and add-on configuration move into a wider scope with more testing days.
Do you need our source code, Helm charts or Terraform?
No. Testing is black-box against the running cluster and its IAM configuration by default. Sharing Helm charts, Kubernetes manifests or the Terraform or CloudFormation that provisions the cluster is optional, and it speeds up scoping the access entries, IRSA roles and network policies we would otherwise have to reconstruct from the live cluster.
Does AWS require approval before we test our EKS cluster?
AWS’s customer penetration-testing policy names specific services you can test without prior approval, including EC2 instances, ECS and Fargate, but it does not name Amazon EKS separately. In practice this follows the shared responsibility model: the EKS control plane, the API server and etcd, is AWS-managed infrastructure you cannot test directly, while the EC2 instances or Fargate profiles running your workloads, your IAM configuration and the Kubernetes objects inside your cluster are yours to test. We confirm AWS’s current policy against your account during scoping.
How is this different from your Kubernetes penetration testing or AWS cloud security review?
Our Kubernetes penetration testing covers any cluster, including self-managed clusters and other clouds, from RBAC and pod security upward. Our AWS cloud security review covers your wider AWS account and IAM estate across every service you run. This page is the layer in between: access entries, aws-auth, IRSA, EKS Pod Identity and the endpoint and add-on configuration unique to running Kubernetes on EKS. Most clients scope this alongside one or both of the others.
What is out of scope for a single-cluster EKS review?
The EKS control plane itself, the API server and etcd that AWS operates, is out of scope; that infrastructure is not yours to test and we do not attempt it. Applications running inside the cluster get their own web application or API penetration test, scoped separately, and a wider AWS account review beyond this one cluster sits with our AWS cloud security review.
Do you test EKS Auto Mode clusters?
Yes. EKS Auto Mode moves capabilities such as the Pod Identity agent and the load balancer controller onto AWS-owned infrastructure rather than running them as pods you manage, but the identity, RBAC, network policy and endpoint questions are unchanged. We confirm which add-ons and controllers are AWS-managed under Auto Mode during scoping so we test the layer you actually control.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your EKS cluster
Get the IAM mapping wrong and Kubernetes RBAC never even sees the request that just became cluster-admin. We test the access entries, aws-auth bindings, IRSA and Pod Identity roles behind it. CREST-certified testers, fixed price from £3,740 for a 3-day single-cluster scope, quoted within 24 hours.
