Overview
Fast-growing Indian SaaS and fintech teams often adopt Kubernetes before anyone owns platform security. Clusters pick up broad service accounts, shared namespaces and secrets sitting in plain manifests. We assess EKS, AKS, GKE and self-managed clusters from two starting points, a compromised pod and a leaked kubeconfig, and show which settings would close each path. Findings are mapped to the CIS Kubernetes Benchmark.
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 Indian clients
- Fixed-price proposals in INR, with 18% GST shown separately on every invoice
- Remote-first delivery from Ahmedabad in IST working hours; on-site work can be discussed at scoping
- Signed authorisation, an NDA on request and agreed testing windows before any activity begins
- Reports and closure evidence shaped for RBI, SEBI CSCRF, IRDAI, DPDP, ISO 27001 and PCI DSS reviews
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
- CERT-In Directions 2022
- RBI IT Governance Direction 2023
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.
Can internal and Active Directory testing be done without a site visit?
Usually, yes. We connect through a VPN you provide or a small preconfigured device that your team plugs in at the office. On-site work can be discussed at scoping where a network needs it.
Will you look at our CERT-In log and time-sync settings?
When infrastructure is in scope, we note whether logs appear to be kept for the 180 days the 2022 CERT-In Directions require and whether systems sync time with NIC or NPL servers. Treat this as a technical observation, not a legal opinion.