Overview
Kubernetes runs a large share of US SaaS products, and one permissive service account can expose every tenant in a cluster. We test from the positions that matter: a compromised pod, a developer credential and the network edge of the cluster. The report shows how far each position reaches, including whether a workload identity leads into the underlying cloud account.
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 US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
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
- PCI DSS v4.0.1 Req. 11.4
- NIST SP 800-171
Frequently asked questions
Do you need cluster-admin access to test?
No. A realiztic 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.
Does an internal and external test cover PCI DSS Requirement 11.4?
It can, when scoped for it. PCI DSS v4.0.1 wants penetration tests from inside and outside the network every year and after significant changes, following a documented methodology, plus proof that segmentation holds. We aren't a QSA or ASV, so quarterly ASV scans and the assessment itself stay with those firms.
Can you test our US networks without traveling?
Network, Active Directory, cloud and Kubernetes testing run remotely through a VPN account, jump host or small test device you place on the network. Wireless and hardware work need someone near the equipment; tell us the sites at scoping and we'll say plainly whether and how we can cover them.