Container and Kubernetes Security Testing

Image and supply chain

• ▸Known vulnerable OS and language packages in the image layers
• ▸Secrets committed into layers: keys, tokens, kubeconfig fragments, .env files
• ▸Base image currency and provenance, and whether tags are pinned to digests
• ▸Build-time tooling left in the final image (compilers, package managers, debug shells)
• ▸Registry trust: unsigned images, mutable tags, missing admission controls

Runtime configuration

• ▸Containers running as root, or with unnecessary Linux capabilities
• ▸Privileged pods, host namespace sharing (PID, network, IPC), hostPath mounts
• ▸Missing or permissive security contexts, seccomp and AppArmor profiles absent
• ▸Resource limits unset, allowing one workload to starve a node
• ▸Automounted service account tokens where the workload needs no API access

Kubernetes access control

• ▸RBAC roles broader than the workload requires, including wildcard verbs and resources
• ▸Service accounts able to read secrets across namespaces
• ▸Paths from a pod service account to cluster-admin
• ▸Namespace isolation: whether a compromised workload can reach another tenant's services
• ▸Exposed dashboards, kubelet endpoints and metrics services

Network and reachability

• ▸Absent NetworkPolicies, so any pod can reach any pod
• ▸Internal services reachable from workloads that should not see them
• ▸Cloud metadata endpoint reachable from pods (the path to node credentials)
• ▸Egress unrestricted, enabling data exfiltration and command-and-control
• ▸Ingress and service exposure that publishes an internal service by accident

Application layer inside the cluster

• ▸The same authorisation, injection and business-logic testing the workload needs regardless of packaging
• ▸Service-to-service calls that trust an internal caller without verifying identity
• ▸Secrets read from environment variables and leaked through error output or logs
• ▸Sidecar and init container behaviour that widens the trust boundary

We already scan our images. What are we missing?

Everything that depends on how the container runs rather than what is inside it. An image with zero known vulnerabilities, running as root with a hostPath mount and an automounted token that can read secrets cluster-wide, is a serious finding that no image scanner will report — because nothing in the image is wrong.

The categories image scanning cannot see: privilege and capability configuration, network reachability between workloads, RBAC paths to cluster-admin, cloud metadata exposure, and the application flaws inside the workload. Those are also the ones that turn one compromised pod into an incident.

Do you need access to our cluster?

For application-layer testing, no: we test the exposed workload the way an attacker would, from outside. That covers the authorisation, injection and business-logic classes that matter most and needs nothing but a URL and credentials.

For runtime posture and RBAC analysis, we need read access — a scoped service account with read-only permissions, or exported manifests and RBAC policies if you prefer not to grant access at all. We never require write access, and no test deletes or restarts anything.

How does this fit with Kubernetes we do not manage ourselves?

Managed control planes (EKS, GKE, AKS) move part of the boundary to your provider, and testing respects that: we do not attempt to escape into a control plane you do not own. What remains yours is the larger half — workload configuration, RBAC, network policy, secrets handling and the applications themselves.

In practice most findings in managed clusters are in exactly that half, because the provider hardens the control plane and the defaults for everything else are permissive.

What does container security testing cost?

A manual cluster review from a consultancy is typically a five-figure engagement, priced by consultant days, and gives you a point-in-time report. Image scanning is often bundled into your registry or CI provider at little or no extra cost, and covers only images.

Penetrify runs continuously from $100 a month with retests included, which is the model that matches how clusters change — a NetworkPolicy edited on Tuesday is tested on Tuesday. For a compliance-driven annual review, keep one human engagement and use continuous testing for the other fifty-one weeks.

Each finding with severity, the manifest, policy or layer that causes it, reproduction steps, and the specific change that fixes it.

The path from one compromised container to something that matters, documented end to end rather than as unrelated tickets.

What a given pod can reach today: which services, which secrets, which namespaces. The input to a NetworkPolicy or RBAC decision.

What closed, what regressed and when — the evidence auditors and enterprise reviewers ask for.

CC6.1: logical access controls, which in a cluster means RBAC and network segmentation evidence

A.12.6: technical vulnerability management including the container supply chain

Requirement 11.4.1 pentest methodology; segmentation testing where containers sit in or beside the cardholder data environment

45 CFR §164.308(a)(8): evaluation of technical safeguards, including workloads processing ePHI

Container security guidance: image, registry, orchestrator, runtime and host layers