Kubernetes & Container Security

A cloud posture review assesses your provider account — IAM, storage, networking — against benchmarks. This assessment goes inside the cluster: the control plane, RBAC, pod security, runtime escape, network policies and the container supply chain. Crucially, it is attacker-led — we don’t just check settings, we attempt privilege escalation and container breakout from a compromised-pod foothold to prove what an intruder could actually reach.

Yes. We assess managed services — Amazon EKS, Azure AKS and Google GKE — as well as self-managed and on-prem clusters. For managed platforms we review the shared-responsibility boundary specifically: what the provider secures versus the RBAC, workload, network-policy and node configuration that remains yours, which is where most exploitable weaknesses sit.

We baseline against the CIS Kubernetes Benchmark and the platform-specific CIS guides for EKS, AKS and GKE, and we map attacker activity to MITRE ATT&CK for Containers. We also align with NSA/CISA Kubernetes hardening guidance and Pod Security Standards, so findings map both to a recognised control and to the real technique an adversary would use.

No. Configuration and RBAC review is read-only. Active attack-path testing — privilege escalation, container escape, lateral movement — is carefully controlled, scoped and scheduled, and we strongly recommend running it against a staging or representative non-production cluster where possible. Where production testing is required, we use production-safe techniques, agree rules of engagement up front and notify you immediately of any critical finding.

You receive risk-rated findings proven by exploitation, each mapped to the CIS control it breaches and to MITRE ATT&CK for Containers, with concrete hardening guidance for your platform team and an executive summary. Re-testing after remediation is available to confirm closure, and Enterprise engagements can integrate checks into your CI/CD pipeline so regressions are caught before they ship.