AKS Security Review
An Azure Kubernetes Service (AKS) cluster does not have one access boundary, it has several. We test Entra ID, RBAC, workload identity and node identity as parts of the same system. 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.”
AKS layers Entra ID authentication, a chosen RBAC model, workload identity for pods and a separate kubelet identity for nodes on top of each other, and a gap in any one changes what a compromised account or pod can reach.
Why AKS security depends on which identity is actually in control
Azure Kubernetes Service can authenticate every sign-in through Microsoft Entra ID and authorise access with Kubernetes RBAC, Azure RBAC for Kubernetes Authorization, or a mix of both, and Microsoft’s own AKS security concepts documentation confirms that AKS Automatic clusters ship with Azure RBAC for Kubernetes authorisation preconfigured, while AKS Standard clusters choose which authorisation model to run. Local Kubernetes accounts, including the certificate-based cluster-admin credential, can be disabled entirely once Entra ID integration is in place, so we test whether that setting is actually applied on the cluster in scope and what a kubeconfig issued before it was enabled can still reach.
Pods and nodes authenticate to Azure through two identities that are easy to conflate. Microsoft Entra Workload ID lets a pod exchange its own Kubernetes service account token for an Entra token through a federated identity credential scoped to a namespace and service account, with a limit of 20 credentials per managed identity, while the kubelet identity every node runs under exists to authenticate to Azure Container Registry and carries no permissions until an ACR pull role is attached to it, whether directly or through an Entra group. We test which workloads hold a federated credential and what its Azure role actually permits, and separately, what the node-wide kubelet identity in scope can reach, since Microsoft’s own ACR integration documentation notes that a role granted through a group can take longer to take effect than a direct assignment.
The API server itself uses a public IP address and FQDN by default and can be narrowed with authorised IP ranges or removed from the internet entirely with a private cluster, all pods can send and receive traffic without limitation until a network policy engine such as Azure NPM, Calico or Cilium is enabled and policies are actually applied, and Azure Policy’s built-in pod security baseline initiative can be left in audit mode, which flags a violation without blocking it. We test which of these controls are configured against what your business intended, alongside the node image versions and Key Vault secret access your node pools and workloads actually use. For workloads on other Kubernetes distributions or a wider Azure estate, our Kubernetes penetration testing and Azure cloud security review cover the platform beyond a single cluster.
SCOPE
What we pen test on an AKS cluster
Entra ID Integration and Local Accounts
AKS clusters can route every sign-in through Microsoft Entra ID and disable local Kubernetes accounts entirely, including the certificate-based cluster-admin credential, once that integration is in place. We test whether local accounts are actually disabled on the cluster in scope, and if not, what a leaked kubeconfig with the built-in admin credential can still reach.
Kubernetes RBAC vs Azure RBAC Authorisation
AKS supports two authorisation models for the Kubernetes API: Kubernetes RoleBindings and ClusterRoleBindings matched to an Entra user’s UPN or object ID, or Azure RBAC for Kubernetes Authorization, which checks Azure role assignments such as Azure Kubernetes Service RBAC Admin instead. We test which model the cluster runs and whether the roles or bindings in place match who your business intends to hold namespace or cluster-wide access.
Workload Identity and Federated Credentials
Microsoft Entra Workload ID lets a pod exchange its Kubernetes service account token for an Entra token through a federated identity credential, with the service account annotated to a specific client ID and up to 20 credentials allowed per managed identity. We test which namespace and service account each federated credential trusts, and whether the Azure role assigned to that identity is scoped to what the workload actually needs.
Kubelet Identity and ACR Pull Access
The kubelet identity that authenticates every node to Azure Container Registry carries no permissions by default and only gains the AcrPull role once a registry is attached, whether directly or through an Entra group. We test which registries the kubelet identity in scope can actually pull from, and whether attaching it through a group has left broader access in place than a direct role assignment would.
API Server Exposure and Private Clusters
The AKS API server uses a public IP address and FQDN by default, and that exposure can be narrowed with authorised IP ranges or removed entirely with a private cluster restricted to your virtual network. We test what the API server endpoint in scope actually accepts connections from, and whether the ranges or private networking configured match what your infrastructure needs rather than the wider default.
Network Policies Between Pods
AKS pods can send and receive traffic without limitation until a network policy engine, Azure NPM, Calico or Cilium, is running and policies are actually applied to the namespaces in scope. We test whether a policy engine is enabled, what the applied policies allow between namespaces, and whether a pod that should only reach its own backend can in practice reach others on the same cluster.
Pod Security via Azure Policy
Azure Policy for AKS enforces cluster guardrails through the same azure-policy Gatekeeper add-on used across Kubernetes, including a built-in initiative for pod security baseline standards that can run in audit mode, which only flags a violation, or deny mode, which blocks it. We test which pod security policies are actually assigned, in which mode, and whether a workload running privileged, host-networked or root-level containers would be stopped or just logged.
Key Vault Secrets Provider for Pods
The Azure Key Vault Provider for Secrets Store CSI Driver mounts secrets, keys and certificates into a pod through a SecretProviderClass, can sync them to a native Kubernetes Secret, and supports autorotation of both the mounted files and the synced secret. We test which identity each SecretProviderClass uses to reach the vault, whether syncing to a Kubernetes Secret has widened access beyond the pods that mount the volume directly, and whether rotation is actually enabled.
Node Pools and Node Image Upgrades
AKS ships new Linux node images weekly and new Windows node images monthly, and a node pool left on manual upgrades can run for months on an image that predates fixes already available through node OS auto-upgrade channels. We test the node image version actually running against the latest available for each node pool, and whether the host carries privileges or exposed services beyond what the workloads scheduled on it need.
Storage and Wider Azure Service Connections
The AKS control plane identity holds the Contributor role over the node resource group by default, covering the Azure Disk, File and Blob CSI drivers it uses to provision storage alongside load balancers and public IPs, so a compromised control plane identity reaches further than the cluster itself. We test what that identity and any workload-facing storage connection can actually reach in your subscription, beyond the storage, queues or blobs the application in scope is meant to use.
OUR PROCESS
Azure Kubernetes Service Security Review: From Scope to Attestation
Scope and Access
We agree which AKS clusters, namespaces and subscriptions are in scope, plus a kubeconfig or Entra credential for every access tier you want tested and read access to the AKS resource in Azure to review configuration.
Identity and Configuration Mapping
We map the RBAC model in use, whether local accounts are disabled, every workload identity’s federated credentials and the kubelet identity’s role assignments, alongside network policy, Azure Policy and node image configuration.
Manual Testing
A CREST-certified tester manually tests RBAC and Azure RBAC boundaries, workload and kubelet identity scope, API server exposure and network policy enforcement, chaining findings where they compound.
Attestation 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 AKS 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 Azure Kubernetes Service 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 AKS 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 Azure Kubernetes Service 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 AKS cluster?
We need a kubeconfig or Entra credential for every access tier in scope, from a namespace-level view through to an account holding Azure Kubernetes Service RBAC Admin or Kubernetes cluster-admin, plus read access to the AKS resource in the Azure portal or CLI to review configuration such as authorised IP ranges, node image versions and Azure Policy assignments. A subscription-level Reader role speeds up configuration review but is not required to run the manual test itself.
Will testing touch live data?
We test the cluster, namespaces and Azure resources you nominate, working against your actual RBAC bindings, workload identities and configuration rather than a copy, so we agree exclusions such as production data stores or customer-facing services before testing starts. We do not run destructive tests or export real customer data without that agreement in writing.
Do you test the underlying AKS control plane or just our cluster?
No. Microsoft manages, patches and secures the Kubernetes control plane itself, since each AKS cluster runs its own single-tenanted, dedicated Kubernetes primary providing the API server and scheduler as part of the managed service. We test what you configure on top of it: Entra ID and RBAC, workload identity, network policies, pod security, node pools and the Azure services your cluster connects to.
What is out of scope for a single-cluster AKS review?
We never test Microsoft’s own AKS control plane infrastructure, and an application running inside the cluster with its own separate attack surface, such as a public API or web front end, is scoped and quoted alongside our wider web application or API testing. We test the identity, authorisation, network and configuration layers you control on the AKS cluster and node pools you nominate.
Does Microsoft have a policy on penetration testing AKS and other Azure services?
Yes. Microsoft has not required pre-approval to penetration test Azure resources you own since 15 June 2017, but testing must still follow Microsoft’s penetration testing rules of engagement for its cloud services, which set out who can test, what written authorisation a third party needs, and activities that stay prohibited regardless of authorisation, such as denial-of-service testing. We confirm the current rules of engagement with you during scoping and work within them.
How long does an AKS security review take?
A single AKS cluster, with a limited number of node pools, namespaces and Azure service connections in scope, sits in our 3-day single-cluster scope, with a report typically landing around 5 working days after kickoff. More clusters, node pools, or a wider set of connected Azure services moves into a larger scope with more testing days.
Do you test workload identity and the Azure resources our pods connect to?
Yes. We test the federated credentials configured for Microsoft Entra Workload ID, what each identity’s Azure role assignment actually permits, and the Key Vault, storage or other Azure services those workloads reach through it. A separately hosted Azure service that another team owns and connects to your cluster is scoped and quoted on its own.
Are your testers CREST certified?
Yes. Every AKS engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
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 AKS security review
An Azure Kubernetes Service (AKS) cluster does not have one access boundary, it has several. We test Entra ID, RBAC, workload identity and node identity as parts of the same system. CREST-certified testers, fixed price from £3,740 for a 3-day single-cluster scope, quoted within 24 hours.
