← Penetration testing
Specialist penetration testing

Kubernetes security testing

We test your clusters the way an attacker would approach them: from the internet, from a compromised workload and from a leaked credential. Then we show you exactly how to close the paths we find.

Scope your test

Delivered under Layer 7's CREST accreditation for penetration testing, by our own in-house testers. See our accreditations

Why it matters

Why Kubernetes needs its own test

Kubernetes is powerful and permissive by default. A single over-privileged service account, privileged pod or missing network policy can turn one compromised application into control of the whole cluster, and often the cloud account behind it.

A standard infrastructure test sees the cluster from the outside. We also test from the inside, assuming a workload has been compromised, because that's where most of the real risk sits.

Scope

What we look at

Control plane and API server

Exposure of the API server, kubelet and dashboards, authentication methods and anonymous access.

RBAC and service accounts

Roles, bindings and service account tokens checked for privilege that lets an attacker escalate or move sideways.

Workload and pod security

Privileged containers, host mounts, capabilities and Pod Security Standards that decide whether a pod can escape to the node.

Network policy and segmentation

Whether workloads, namespaces and the cloud metadata service are reachable from places they shouldn't be.

Secrets management

How secrets are stored, mounted and exposed to workloads, including environment variables and external secret stores.

Cloud integration

Workload identity and IAM on managed platforms such as EKS, AKS and GKE, where cluster access becomes cloud access.

Our approach

How we test it

  1. 01

    External view

    We map what an attacker on the internet can see and reach: exposed endpoints, ingress and management interfaces.

  2. 02

    Assumed breach

    Starting from a compromised pod, we test how far an attacker can go: other workloads, secrets, the node and the cloud account.

  3. 03

    Configuration review

    We review cluster configuration against recognised guidance such as the CIS Kubernetes Benchmark, so nothing relies on luck.

What we find

Common weaknesses

Every finding comes with evidence, a risk rating and practical remediation guidance, and a free retest once it's fixed.

  • Over-privileged service accounts

    Tokens that can read secrets or create pods cluster-wide, handed to workloads that never needed them.

  • Pods that can escape to the node

    Privileged containers or host path mounts that give a compromised workload control of the underlying host.

  • Flat cluster networks

    No network policy, so any compromised pod can talk to every other service in the cluster.

  • Reachable cloud metadata

    Pods that can query the cloud metadata service and pick up the node's cloud credentials.

  • Exposed management interfaces

    Dashboards, kubelet APIs or the API server reachable from networks that shouldn't see them.

How it fits together

Build, package, run

Pipelines, images and clusters are one chain, and attackers move along it. Test one link, or the whole path from commit to running workload.

  1. Build

    CI/CD pipeline review

    Where code becomes an image. We check who can change what gets built, signed and pushed, and what the pipeline can reach in production.

    Learn more
  2. Package

    Container security review

    What's inside each image and how it behaves running in its pod: the tooling, privileges and exposed services an attacker would inherit.

    Learn more
  3. Run

    Kubernetes security testing

    The cluster that schedules and connects your pods: identities, network policy, secrets and the control plane around every workload.

    You're on this page
FAQ

Common questions

Do you need access to our production cluster?

Not necessarily. We can test a representative staging cluster, or agree read-only access and a testing window for production during scoping.

Do you test managed Kubernetes such as EKS, AKS and GKE?

Yes. Managed platforms take the control plane off your hands, but workloads, RBAC, network policy and the cloud identity integration are still yours to secure.

How is this different from a container review?

A container review goes deep on individual workloads: the image, and the running container tested from inside its pod. Kubernetes testing looks at the cluster around them: how workloads, identities and networks fit together, and how far an attacker can go once inside. Together with a CI/CD pipeline review they cover the whole path from build to running workload.

Specialist testing

More specialist testing

Build chainCI/CD pipeline reviewLearn moreImages and podsContainer security reviewLearn moreDesktop appsThick client penetration testingLearn moreIdentityActive Directory security reviewLearn moreAdversary simulationOffensive security & red teamingLearn more

See all our penetration testing

Between tests: attack surface management and continuous vulnerability management.

Find out what a compromised pod could reach

Tell us what you need tested and we'll give you a fixed-price quote and a clear scope, with a free retest included.

Scope your test