Vulnerability assessment and penetration testing guide
A container-image scan is useful evidence about an image, but a Kubernetes service includes more than its software packages. A buyer should understand who operates the cluster, which workloads were assessed, how administrative access is controlled, and what separates customers or teams.
Separate the application, workload and control plane
The application provides customer functions. Workloads run that application and use identities, configuration, storage, and network connections. The control plane manages the cluster. An assessment may cover one layer without covering the others. Ask the vendor to label those boundaries explicitly rather than describing all work as a “Kubernetes penetration test.”
- Application layer: customer-facing APIs, permissions, and data handling.
- Workload configuration: service identities, privileges, approved images, secrets handling, and connectivity.
- Cluster administration: access to management functions, authorization, policy enforcement, and change records.
- Supporting services: registries, deployment pipelines, storage, and cloud permissions supporting the assessed service.
Ask what isolation means in this architecture
Kubernetes documentation describes namespaces as a way to organize and scope resources, with additional controls needed for workload isolation. A namespace label alone is insufficient evidence that customers cannot affect one another. Ask whether the vendor separates customers at the application, namespace, cluster, or another architectural level, and what evidence supports that design.
For a shared cluster, request a description of the relevant authorization and network-policy boundaries. The official Kubernetes security checklist also highlights workload restrictions, network-policy support, and administrative access. These are discussion areas, not a certification checklist or proof that a deployment is secure.
Account for the managed-service boundary
In a managed Kubernetes offering, the provider may operate parts of the control plane while the vendor remains responsible for workload settings and other customer-controlled configuration. Ask for the responsibility split for the selected service and deployment model. Do not assume the assessor can test provider-operated components simply because the vendor runs workloads there.
Record the cluster population, deployment model, environment, configuration date, and representative workloads. A sandbox cluster can be useful, but its conclusions need a documented relationship to production. Pay particular attention to differences in identity, policy enforcement, networking, and data services.
Evidence a customer can reasonably request
A concise evidence package can include the scope summary, architecture and responsibility summary, assessed policy areas, material findings, exceptions, and retest status. It should distinguish image or dependency scanning from configuration review and authorized testing. A full export of cluster secrets or confidential infrastructure configuration is unnecessary for ordinary procurement review.
Consider a vendor that supplies recent image-scan results but no evidence about cluster administration. Ask who reviewed the management boundary and where that conclusion is documented. Do not infer that boundary coverage from the number of images scanned.
Fix the source of the configuration
A workload owner, platform team, and cloud identity team may all be involved in one remediation. Assign an accountable owner and identify the durable configuration source, such as the approved deployment definition or policy. Confirm the change applies to relevant workloads, not just the sample discussed in a report.
Retest material findings and retain the assessed configuration or release reference. Record exceptions with an owner and review date. Changes to the cluster model, workload privileges, identity integration, or customer-isolation design should trigger a decision about fresh assessment evidence.
Sources and scope of this guidance
The questions and examples above are buyer guidance, not a claim that a particular law or assurance standard requires every activity. Match the engagement to your risks, obligations, and written authorization.