Vulnerability assessment and penetration testing guide
A container-image scan is useful evidence about an image, but a Kubernetes assessment also needs a defined cluster and workload scope. Platform, application, and security owners should identify who operates each layer, which workloads and identities are included, how administrative access is controlled, and which isolation boundaries the service depends on.
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. Label those boundaries explicitly in the assessment plan 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. Document whether your architecture separates customers or teams at the application, namespace, cluster, or another level, and identify which controls enforce that design.
For a shared cluster, include the relevant authorization and network-policy boundaries in the review scope. 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 your organization remains responsible for workload settings and other customer-controlled configuration. Document the responsibility split for the selected service and deployment model. Your use of the service does not authorize testing of provider-operated components; scope and provider policies still govern the work.
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 the assessment should produce
The assessment record should identify the cluster population, representative workloads, configuration dates, policy areas reviewed, material findings, exceptions, and retest status. Separate image and dependency scan results from configuration review and authorized testing. Keep sensitive configuration evidence in an approved restricted location; do not place secret values in the report.
For example, current image-scan results can coexist with an unreviewed cluster-administration boundary. Assign that boundary a specific assessment objective and identify the authorization and configuration evidence needed to evaluate it. The number of images scanned does not establish administrative-control coverage.
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 scope questions and examples above help system owners plan an assessment; they are not a claim that a particular law or assurance standard requires every activity. Match the engagement to your architecture, risks, obligations, and written authorization.