Offensive Security

Cloud & Kubernetes Security

Cloud accounts and Kubernetes clusters tested the way an attacker moves through them: from an over-broad role or a leaked token to the data behind it.

Most cloud incidents are not exotic exploits. They are an over-broad IAM role, a secret left in a build log, a pod that can reach the node it runs on, or a workload identity trusted far more widely than anyone checked. We look for the path an attacker would take through the account and the cluster, then we walk it to show where it ends.

We review the account and the cluster together, because the findings that matter usually live in the seam between them: the role a pod assumes, the metadata endpoint it can call, the token that turns a single container into control of the whole cluster. Automated tooling narrows where to look. It does not decide what counts, and it does not write the report.

Usually, one of these is true

An enterprise customer or an auditor asks for an independent test of your cloud environment, not just a screenshot of a passing benchmark.
You have moved workloads into Kubernetes and nobody has checked what a single compromised pod can reach from inside the cluster.
IAM roles and trust policies have grown for years, and no one can say with confidence which identity can assume which.
A secret turned up in a build log or a public repository and you need to know how far it could have been used before it was rotated.

What we test

The review covers the cloud account and the cluster as one system, on the environment you actually run, with access scoped and agreed before anything starts.

Identity and privilege paths. IAM roles, trust policies and role chains, and the escalation routes that turn a low-value identity into account takeover, including the workload identities bound to pods.
Kubernetes RBAC and workloads. Role and cluster-role bindings, service account tokens, admission control, pod security context, host mounts, and workloads granted more than they use.
Account configuration. Public exposure, logging and encryption defaults, and the drift between what the infrastructure code declares and what is actually running.
Secrets and credentials. Secrets in build logs, environment variables, images and repositories, how they are scoped, and what a leaked one still opens before it is rotated.
Network and lateral movement. What a single compromised workload reaches: namespace and network policy boundaries, security groups, peering, and the instance metadata service.
Container and node breakout. Privileged containers, escapes to the underlying node, the kubelet credentials that follow, and what a node compromise gives up about every pod on it.

How the test runs

One named engineer, one shared channel, and findings in that channel as they are confirmed rather than in a report at the end.

Scope and access. We agree the accounts, clusters and objectives in writing, set the rules of engagement, and take read access first, escalating only where a specific test requires it.
Mapping. We enumerate identities, roles, workloads and network reachability to build a picture of what can reach what, before touching anything.
Path testing. We walk the reachable paths by hand: privilege escalation, workload identity abuse, container breakout and lateral movement across the account and cluster boundary.
Live reporting. Each finding reaches your channel with a reproduction, a CWE mapping and a CVSS v4.0 rating as it is confirmed. Anything critical is reported within the hour.
Retest and attestation. Once fixes land we retest the paths we walked and issue a letter of attestation covering what was tested and what now holds.

What you get

The reachable path, demonstrated. Each attack path walked end to end, from starting identity to final access, with the reproduction attached.
A report you can act on. Findings mapped to CWE and rated with CVSS v4.0, written by the engineer who found them, for the team that owns the account.
Remediation at the configuration level. Fixes described against your IAM policies, RBAC and cluster settings, not generic benchmark language.
A retest and a letter of attestation. After fixes land, we retest the paths and issue an attestation you can hand to a customer or an auditor.
Direct access to the engineer. One named engineer on the shared channel throughout, with no account-manager layer in between.

What we need from you

Read-only access to the cloud accounts and clusters in scope, with a route to request higher privilege where a specific test needs it.
A named contact on your side who can answer questions about the architecture and approve any step that carries risk.
Confirmation of which accounts, subscriptions, projects and clusters are in scope, and anything that must not be touched.
Where a managed provider requires notice or authorisation for testing, the account details we need to file it.
Architecture notes or diagrams if you have them: what runs where, and which data each environment holds.

What we can show you

Research, not only testing. Our work has been acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense, and our researchers have published 70+ CVEs. The same habits apply to your cloud.
The path, not a checklist. We show the route from a starting identity to real access, mapped to CWE and rated with CVSS v4.0, rather than a list of failed benchmark items.
Access held carefully. Mutual NDA and PGP before you share anything. Credentials and evidence stay encrypted, least-privilege, limited to the engineers on the engagement, and destroyed after the retest on request.
Testing that becomes hardening. One team runs the test, the hardening that keeps findings closed, and the platform engineering to rebuild what needs it, so a finding can become a fix without a hand-over.

Standards we work to

We structure the review against the public benchmarks and threat models your team and your auditors already recognise.

CIS Benchmarks
NSA/CISA Kubernetes Hardening Guidance
MITRE ATT&CK for Cloud
MITRE ATT&CK for Containers
CVSS v4.0
CWE

Common questions

Do you test our production environment or a copy?

Either, and we agree which before we start. Production gives the most accurate result, so read-only access and careful, non-disruptive testing are the default there. Where a change carries risk, we clear it with your named contact first, and destructive checks are run in a staging cluster.

Do we need to notify our cloud provider?

Sometimes. Testing your own resources on the major providers is generally allowed without prior approval, but some activities, such as command-and-control traffic or simulated events, require a form filed in advance. We tell you what applies to your setup and file it with you before any of it runs.

Is this a configuration scan or a penetration test?

A penetration test. A scanner reports that a setting deviates from a benchmark; we show whether that deviation is actually reachable and where the path ends. Tooling narrows where to look, but a person decides what counts as a finding and walks the path by hand.

What happens if you reach cluster admin or account takeover?

We stop at proof. We capture enough to reproduce the path, report it to your channel immediately, and confirm anything critical within the hour of confirming it. We do not exfiltrate real data or disrupt running workloads to make the point.

How long does it take and what does it cost?

Both are a fixed price and fixed dates, agreed when we scope the work and written into the scope before anything starts. The figures depend on the number of accounts and clusters, their size, and whether the cluster review runs alongside the account review.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.