GKE Security Review
In Google Kubernetes Engine (GKE), a workload’s real permissions come from IAM, node identity and RBAC layered together, and one loose layer defeats the rest. We test how those layers actually combine. 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.”
GKE’s control plane exposes a DNS-based endpoint and an IP-based endpoint, and which one a cluster actually uses, alongside how tightly authorised networks are set, decides who can reach it at all.
Why GKE security comes down to IAM, RBAC and the identity each workload actually holds
Google Cloud’s own IAM reference for GKE lists Kubernetes Engine Admin (roles/container.admin), which provides access to full management of clusters and their Kubernetes API objects, alongside Kubernetes Engine Developer (roles/container.developer), which only reaches Kubernetes API objects inside clusters. Those project-level IAM roles decide who can reach a cluster at all, while Kubernetes RBAC decides what that identity can do to objects once connected, and Google’s own Google Groups for RBAC feature lets one RoleBinding grant that access to an entire Google Workspace group added to the gke-security-groups group, rather than to named accounts one at a time.
Identity inside the cluster works the same way round. Workload Identity Federation for GKE lets an individual Pod authenticate to Google Cloud APIs as its own IAM service account, through a Kubernetes ServiceAccount annotated with iam.gke.io/gcp-service-account, rather than inheriting whatever identity the node itself runs as. By default GKE runs nodes on the Compute Engine default service account unless you specify one, and Google’s own hardening guidance warns that account can already hold more permissions than the cluster needs if it is reused elsewhere in the project. Enabling Workload Identity with the GKE_METADATA node pool flag also replaces the older, now-deprecated metadata concealment approach, which Google states is incompatible with Workload Identity once it is switched on.
The control plane itself has two kinds of endpoint, a DNS-based endpoint and an IP-based endpoint, and Google recommends the DNS-based endpoint for simplified, policy-based access, with a separate best practice to define control plane authorised networks that limit which addresses can reach it at all. How much of that configuration is even yours to change depends on the mode: in Autopilot, Google manages node infrastructure, scaling and a set of security defaults such as Shielded GKE Nodes, while a Standard cluster leaves every one of those switches, and the responsibility for using them, with your own team. For the wider container platform family this scope splits from, see our OpenShift penetration testing page, and our Kubernetes penetration testing page for self-managed clusters.
SCOPE
What we review in a GKE cluster
IAM Roles and Kubernetes RBAC Interplay
Project-level IAM roles such as Kubernetes Engine Admin (roles/container.admin) and Kubernetes Engine Developer (roles/container.developer) decide who can reach a cluster at all, while Kubernetes RBAC decides what that identity can do to objects once connected, and Google Groups for RBAC lets a single RoleBinding grant that access to an entire Google Workspace group through the gke-security-groups group. We test how IAM roles and RBAC bindings actually combine for every identity in scope, and whether a broad IAM role quietly reaches further than the RBAC restriction meant to contain it.
Workload Identity Federation for GKE vs Node Service Account
Workload Identity Federation for GKE lets a Pod authenticate to Google Cloud APIs as its own IAM service account through a Kubernetes ServiceAccount annotated with iam.gke.io/gcp-service-account, instead of inheriting whatever identity the node itself runs as, and without it every Pod on that node can reach the node’s own service account. GKE runs nodes on the Compute Engine default service account unless you specify one, and Google’s hardening guidance warns that account can already hold more permissions than the cluster needs if it is reused elsewhere in the project. We test which Pods still have a path to the node identity, and whether Workload Identity bindings actually limit each workload to its own role.
Metadata Server Concealment vs the GKE Metadata Server
Nodes can conceal their metadata endpoint using the older, deprecated –workload-metadata=SECURE flag, but Google states plainly that Workload Identity Federation for GKE replaces the need for metadata concealment altogether and the two approaches are incompatible; enabling Workload Identity instead switches a node pool to the GKE metadata server through –workload-metadata=GKE_METADATA. We test which metadata protection, if any, a node pool actually has enabled, and flag a pool still relying on the deprecated concealment flag, or none at all, over a completed move to Workload Identity.
Control Plane Exposure: Private Clusters, Authorised Networks and the DNS-based Endpoint
A GKE control plane exposes a DNS-based endpoint and an IP-based endpoint, and Google recommends using the DNS-based endpoint for simplified, policy-based access, alongside a separate best practice to define control plane authorised networks that restrict which IP addresses can reach it. We test which endpoint type a cluster actually exposes, how tightly authorised networks are configured against what the architecture needs, and whether a cluster built as private is still reachable from a network it was never meant to serve.
Autopilot vs Standard: Where Google’s Responsibility Ends
In GKE Autopilot, Google manages the underlying node infrastructure, scaling and a set of preconfigured security settings such as Shielded GKE Nodes, while a Standard cluster leaves node management, and whether those same settings are switched on, to your own team. We test each mode against what it genuinely leaves you to configure, so an Autopilot control enforced by default is never assumed for a Standard cluster that has to turn it on deliberately.
Network Policies Between Pods and Services
Every Pod in a GKE cluster can reach every other Pod by default, and turning that off needs both the NetworkPolicy add-on enabled and network policy enforcement switched on for the nodes, since enabling the add-on alone is not enough on its own. We test which namespaces and workloads actually sit behind a NetworkPolicy, and whether a policy that reads as restrictive still leaves an open path between services that should never talk to each other.
Binary Authorization and Deploy-Time Image Trust
Binary Authorization enforces a policy describing the constraints an image must meet before deployment, verified through attestations from a trusted attestor such as a specific build pipeline, so the same verification never has to be repeated at deploy time. We test what your policy actually requires, whether every attestor it trusts still reflects a process you control, and whether an image can still reach the cluster through a path the policy does not cover.
Shielded GKE Nodes, Secure Boot and Integrity Monitoring
Shielded GKE Nodes provide verifiable identity and integrity checks for node VMs, and secure boot and integrity monitoring are always enabled in Autopilot clusters, while a Standard cluster can still have any of the three switched off individually. We test whether Shielded GKE Nodes, secure boot and integrity monitoring are actually enabled on every node pool in a Standard cluster, rather than assumed from the cluster’s mode alone.
Secrets Encryption with Cloud KMS
Application-layer secrets encryption protects Kubernetes Secrets using a Cloud KMS key, and it only takes effect once the Kubernetes Engine Service Agent is granted the Cloud KMS CryptoKey Encrypter/Decrypter role on that key. We test whether this is actually enabled for the cluster in scope, whether the KMS key’s own IAM bindings are as tight as the Secrets it protects, and what happens to Secrets that existed before the feature was turned on.
Workload Access to Other Google Cloud Services
Whatever IAM role a workload’s identity holds, whether the node’s own service account or one reached through Workload Identity Federation for GKE, decides what that workload can do to Cloud Storage, Pub/Sub, Cloud SQL and every other Google Cloud API in the project, not only what runs inside Kubernetes. We test what a compromised or over-permissioned Pod can actually reach outside the cluster, since a role granted for one integration often ends up attached to the identity every workload on the node shares.
OUR PROCESS
Google Kubernetes Engine Security Review: From Scope to Attestation
Scope and Access
We agree which clusters, namespaces, node pools and Google Cloud projects are in scope, plus a Kubernetes and IAM account for every role and privilege tier you want tested.
IAM, RBAC and Identity Mapping
We map every IAM role, RBAC binding, node service account and Workload Identity link against who or what actually needs that level of access.
Manual Testing
A CREST-certified tester manually tests IAM and RBAC interplay, Workload Identity bindings, control plane exposure, network policies and secrets handling, 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 GKE 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 Google Kubernetes Engine 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 GKE 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 Google Kubernetes Engine 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 GKE cluster?
We need read access to the cluster’s IAM policy, RBAC bindings and node pool configuration in the Google Cloud console or via kubectl and gcloud, plus at least one Kubernetes account and one IAM identity for every distinct privilege tier in scope. Where Workload Identity Federation for GKE is in use, we also need to see which Kubernetes ServiceAccounts are annotated to which IAM service accounts.
Will testing touch live data or workloads?
We test cluster configuration, IAM and RBAC, network policy and control plane exposure rather than the data inside your running Pods, and we agree exclusions such as destructive kubectl commands or production-only namespaces before testing starts. We do not export real customer data or run destructive tests without that agreement in writing.
Do you test Autopilot and Standard clusters the same way?
The questions are the same: who can reach the cluster, what RBAC allows once connected, and what the network exposes. What differs is the boundary, since Autopilot manages node infrastructure and enforces some settings, such as Shielded GKE Nodes, by default, so we confirm during scoping exactly what your team controls on your chosen mode and test to that boundary.
What is out of scope for a single-cluster GKE review?
We never test Google’s own infrastructure, the underlying control plane host, or GKE’s managed services themselves, and a separately hosted application that only happens to run on the cluster is scoped and quoted on its own. We test the IAM roles, RBAC bindings, node configuration, network policy, control plane exposure and secrets handling for the cluster you nominate.
Does Google Cloud have a policy on customer penetration testing?
Yes. Google’s published FAQ for Cloud Platform states that you are not required to contact Google before evaluating the security of your own Cloud Platform infrastructure with penetration testing, provided you stay within the Cloud Platform Acceptable Use Policy and Terms of Service and only test your own projects. We confirm those current terms and any account-specific conditions during scoping and test within them.
How long does a GKE security review take?
A single cluster with a typical number of namespaces, node pools and IAM identities sits in our 3-day single-cluster scope, with a report usually landing around 5 working days after kickoff. Multiple clusters, a mix of Autopilot and Standard, or a larger number of Workload Identity bindings moves into a larger scope with more testing days.
Do you need our application source code?
No, not for the cluster review itself. We test cluster configuration, IAM, RBAC and network policy using the access and accounts you provide, and a separate web application or API running on the cluster is scoped and quoted as its own engagement if you also want its code and logic reviewed.
Are your testers CREST certified?
Yes. Every GKE 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 GKE cluster
In Google Kubernetes Engine (GKE), a workload’s real permissions come from IAM, node identity and RBAC layered together, and one loose layer defeats the rest. We test how those layers actually combine. CREST-certified testers, fixed price from £3,740 for a 3-day single-cluster scope, quoted within 24 hours.
