Overview
UK SaaS and fintech platform teams often run customer workloads on shared Kubernetes clusters, where one weak service account can expose every tenant. We test from the position of a compromised pod and of a developer with limited rights, then measure how far each can go. Findings come with the manifest or policy change that would have stopped us.
Kubernetes concentrates a great deal of trust in one place. It schedules workloads, holds secrets, manages identities through service accounts, and controls the network between pods, which means a single misconfigured workload can become a route to the entire cluster. We test from the position that matters most: an attacker who has compromised one container and wants to escape it and escalate to cluster-wide control.
We examine the layers that decide whether that escalation is possible. Role-based access control and service-account permissions often grant far more than a workload needs; pod security settings may allow privileged containers, host mounts or dangerous capabilities that enable a breakout to the node; and network policy may let any pod reach the API server or sensitive services. We also assess the images themselves, hunting for embedded secrets, vulnerable packages and over-privileged base layers, and review how the registry and build pipeline are trusted.
The findings are framed around the real question: what can one bad pod do? We show the path from workload compromise to node access to cluster admin, score each finding with CVSS v4.0, and recommend the controls, tighter RBAC, pod security standards, network policy and image hygiene, that cut the path. The assessment pairs naturally with a cloud review, since the cluster usually inherits power from the account hosting it.
How we work with UK clients
- Testing windows set in UK time at scoping. India runs 4.5 hours ahead during British Summer Time and 5.5 hours ahead in winter, so our days overlap.
- Fixed proposals in GBP, excluding VAT; the reverse charge usually applies to UK business buyers.
- No traffic leaves our hands until written authorisation is signed by someone entitled to give it, as the Computer Misuse Act 1990 requires.
- Findings labelled for the evidence you file: ISO 27001 Annex A, UK GDPR Article 32, PCI DSS or a supplier questionnaire.
What's included
Our approach
- Scope & accessWe agree the cluster, its environment and a workload starting position.
- Configuration reviewWe assess RBAC, pod security, network policy and secrets handling.
- Escape & escalationWe test paths from a workload to the node and on to cluster control.
- Image assessmentImages and the registry are reviewed for secrets and vulnerable components.
- Report & debriefAttack paths are documented, scored and paired with hardening controls.
What you receive
- Workload-to-cluster attack path analysis
- RBAC and service-account permission review
- Image and registry findings with CVSS v4.0 scores
- Pod security and network-policy recommendations
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- CIS Kubernetes Benchmark
- NIST SP 800-115
- MITRE ATT&CK
- OWASP WSTG
- CVSS v4.0
- CWE
- UK GDPR Art. 32
- Cyber Essentials controls
Frequently asked questions
Do you need cluster-admin access to test?
No. A realistic test starts from a low-privilege workload or namespace, because that reflects a compromised pod. We may ask for read access to review configuration efficiently, but the exploitation work deliberately begins from limited privilege.
Which platforms do you cover?
Managed services such as the major cloud offerings and self-managed clusters alike. The core questions, RBAC, pod security, escape paths and image hygiene, apply everywhere, and we also check the platform-specific trust each environment adds.
Should this be combined with a cloud review?
Often, yes. A cluster usually inherits identity and network power from the cloud account hosting it, so a path that looks contained inside Kubernetes may extend into the wider account. Running both gives a complete picture of the blast radius.
What permission do you need before testing our network?
Signed written authorisation from someone entitled to give it, which keeps the work on the right side of the Computer Misuse Act 1990. If a hosting company, landlord or managed IT provider runs part of the estate, we ask you to confirm their permission too.
Is this the same as a Cyber Essentials Plus audit?
No. Cyber Essentials Plus has a Certification Body check, hands-on, that the scheme's five controls are in place. An infrastructure pentest goes further, chaining weaknesses to show real attack paths. Many teams use our findings to tidy up before their Certification Body visits.