Microservices & Container Security Testing
For teams running containerized, service-mesh or Kubernetes-based platforms where a single misconfigured RBAC binding or unauthenticated east-west call can expose the whole cluster. We test the parts a web app pentest never reaches: service-to-service trust, the control plane, image supply-chain and secrets — and prove which paths an attacker can actually pivot along.
What we test
Service-to-service authN/authZ (mTLS & zero-trust)
We verify that east-west calls enforce mutual TLS (PeerAuthentication STRICT), reject plaintext, and that AuthorizationPolicies actually deny by default — not just permissive mode with no allow rules, and no fallback to spoofable X-Forwarded-For / JWT-less identity.
Broken workload identity & token abuse
We attempt to lift ServiceAccount tokens from pods, replay them against the API server, and test SPIFFE/JWT audience and issuer validation — catching over-scoped tokens and missing `aud`/`exp` checks (NIST SP 800-204B ABAC).
Kubernetes RBAC privilege escalation
We map every Role/ClusterRoleBinding for wildcard verbs, `escalate`/`bind`/`impersonate`, secrets-list, `pods/exec`, and node-proxy grants that let a namespace-scoped identity reach cluster-admin.
Network policy & east-west segmentation
Default-deny is usually absent — we prove flat pod networking by pivoting from one compromised pod to unrelated namespaces, kubelet (10250), etcd (2379) and cloud metadata (169.254.169.254) for IMDS credential theft.
Container image CVEs & SBOM integrity
We generate an SBOM (Syft/CycloneDX), scan for exploitable CVEs in OS and app dependencies, flag root-run/privileged images, embedded secrets in layers, and unpinned `:latest` or unsigned images (no cosign/Notation attestation).
Pod & workload hardening (Pod Security)
We hunt privileged pods, hostPath/hostNetwork/hostPID mounts, `allowPrivilegeEscalation`, missing seccomp/AppArmor, and CAP_SYS_ADMIN — the container-escape primitives measured against CIS and Pod Security Standards `restricted`.
Secrets management exposure
We check for plaintext Secrets (base64 is not encryption), secrets in env vars and manifests, missing encryption-at-rest for etcd, and whether external stores (Vault, cloud KMS/CSI) actually gate access rather than mounting everything to every pod.
API gateway & supply-chain (CI/CD)
We test the ingress/API gateway for auth bypass, header smuggling and rate-limit gaps, and review CI/CD for injectable pipelines, over-privileged runners and unverified artifacts (OWASP Top 10 CI/CD, SLSA provenance).
Methodology
- 1
Scoping & architecture recon
We map the trust boundaries with you: namespaces, service mesh (Istio/Linkerd), ingress, registries, CI/CD and cloud IAM. Access model agreed up front — external black-box, an in-cluster foothold pod, and/or read-only kubeconfig — with rules of engagement for a shared cluster (PTES pre-engagement).
- 2
External & API-gateway testing
From outside the cluster we enumerate exposed services, ingress and any internal dashboards inadvertently published (Kubelet, etcd, Dashboard, registries), and test the API gateway for authN/authZ bypass — the attacker's front door, mapped to OWASP API Security Top 10.
- 3
Cluster & configuration assessment
Authenticated review of RBAC, network policies, Pod Security, admission control (OPA/Gatekeeper/Kyverno), API-server flags and etcd encryption, benchmarked against the CIS Kubernetes Benchmark and NIST SP 800-190 — separating theoretical findings from exploitable ones.
- 4
East-west movement & escalation
From an assumed-breach foothold pod we chase real attack paths: token theft, node/metadata credential access, container escape, cross-namespace lateral movement and path-to-cluster-admin, mapped to MITRE ATT&CK for Containers.
- 5
Supply-chain & image analysis
SBOM generation, image CVE and secret scanning, base-image and provenance review, signing/attestation verification (cosign/Notation, SLSA), and CI/CD pipeline abuse paths that let code reach production unverified.
- 6
Reporting, debrief & re-test
Each finding ships with the exact manifest/command to reproduce, cluster context, CVSS v3.1 rating and a concrete remediation (specific policy, not 'harden RBAC'). Live debrief with your platform team, and a free re-test of fixed issues.
Standards & references
What you get
- Technical report with reproducible PoCs — Every finding with the manifest, kubectl/curl command and output to reproduce it, CVSS v3.1 score, affected namespace/workload and a specific fix.
- Attack-path narrative — The assumed-breach kill chain — from foothold pod to cluster-admin or data — mapped to MITRE ATT&CK for Containers, so you see the sequence, not just isolated flags.
- CIS & Pod Security config gap-list — Prioritized benchmark deltas for RBAC, network policy, Pod Security Standards and image posture, marked exploitable vs. hardening-recommended.
- SBOM & image vulnerability inventory — CycloneDX SBOM per scanned image plus a deduplicated, exploitability-ranked CVE list — not raw scanner noise.
- Executive summary & re-test attestation — A one-page risk summary for leadership/compliance, plus a re-test round and letter confirming which findings are closed.
FAQ
Do you need cluster admin access to test?+
No. We tailor access to your risk appetite. The most realistic engagement is assumed-breach: you give us a low-privilege foothold pod and/or a read-only kubeconfig, and we prove what an attacker who lands one container can reach. Pure external black-box and full-config-review options are also available — we agree the model in scoping.
Will the test disrupt our production cluster?+
Testing is non-destructive by default. We avoid resource exhaustion, we don't delete workloads, and any potentially disruptive action (e.g. a controlled container-escape PoC) is called out and run only against a namespace or staging cluster you approve. Rules of engagement and a rollback plan are agreed before we touch anything.
How long does it take and what does it cost?+
A focused single-cluster engagement is typically 5–8 working days; larger multi-cluster or multi-mesh estates run 2–3 weeks. Cost scales with cluster count, namespace/service volume and whether image supply-chain and CI/CD are in scope. You get a fixed quote after a short scoping call — no open-ended billing.
What do we need to provide to start?+
Architecture/threat-model notes if you have them, the target scope (clusters, namespaces, registries, gateway URLs), the agreed access artifact (foothold pod spec or kubeconfig), and a signed authorization. If cloud IAM is in scope we'll ask for a read-only role. That's usually enough to begin within days.
Is this a scanner report or manual testing?+
Both, correctly ordered. Automated tooling (Trivy/Grype, kube-bench, kube-hunter, Syft) gives coverage, but every reported finding is manually verified and chained by a tester — we discard false positives and, more importantly, connect individually-minor misconfigs into a real path to cluster-admin. You get exploitability, not raw scanner output.
Do you cover the container images and CI/CD, or just the running cluster?+
Both, if in scope. We generate SBOMs and scan images for CVEs and embedded secrets, review base images and signing/attestation (cosign, SLSA provenance), and assess the CI/CD pipeline for injectable steps and over-privileged runners — because in microservices the pipeline is often the softest path into production.