Vulnerability assessment and penetration testing guide
A container scan report may be sitting in your audit evidence folder while nobody has explained who can administer the environment or reach the application’s data. Those are separate questions, and the scan alone may not answer them.
Kubernetes helps run and manage applications packaged in containers. If your service uses it, start by asking your technical team what they operate, what a provider handles, and what evidence they have for each part. You don’t need to become an engineer to follow that conversation.
Why does this matter to the audit?
If Kubernetes supports the service in your SOC scope, its security controls may be part of the evidence you need. The useful question is how your team protects the application and information running there. You do not need to become a Kubernetes engineer to ask who owns that responsibility and what evidence supports the answer.
Discuss the planned evidence with your auditor and technical owner. Avoid assuming that a particular scan or a product labeled “Kubernetes penetration test” satisfies every relevant control.
Who is responsible for which part?
Ask your team to explain the environment in four parts:
- The application: what customers use, including its APIs, permissions, and handling of information.
- The workloads: the running application components, their access, settings, and network connections.
- The cluster: the group of resources Kubernetes manages, including who can administer it and enforce policies.
- Supporting services: the systems that store images, deploy changes, provide storage, or control cloud access.
A managed service provider may operate part of this environment. Your organization may still control the workloads and important settings. Have your team document that division instead of assuming “managed” means someone else handles everything.
What should the assessment cover?
Give the following questions to your platform or security owner. Ask for answers tied to the environment supporting your service:
- Who can administer the cluster, and how is that access approved and reviewed?
- What information and systems can each workload access?
- How are customers or teams separated where they share infrastructure?
- How are approved software images, sensitive credentials, and deployment changes managed?
- What evidence comes from image scanning, configuration review, and authorized testing?
- Which clusters or workloads were sampled, and how do they represent production?
“Each customer has a separate namespace. Doesn’t that settle it?” A namespace helps organize and scope resources in Kubernetes. Other controls still have to enforce the intended separation. Ask the team what those controls are and how their operation has been checked.
What should you receive?
Ask for a short explanation you can understand, supported by the technical records. It should identify what was reviewed, when it was reviewed, and what was left out.
- The relevant clusters and workloads, with their environment and configuration dates.
- Results from the different review or testing activities, kept distinguishable.
- Findings, business impact, responsible owners, and planned completion dates.
- Correction and retest evidence, plus decisions about unresolved items.
Keep sensitive technical evidence in an approved restricted location. Reports should describe how credentials are protected without including the secret values themselves.
What if the assessment finds a problem?
Ask which team can make the correction and whether it will reach all affected workloads. A setting fixed in one running instance can return if the deployment process still contains the old setting. The owner should correct the configuration used for future deployments as well.
Retest material corrections and keep the evidence linked to the finding. If the cluster design, permissions, or customer-separation model changes later, have the technical owner decide what needs to be reviewed again. Share significant findings and their treatment with your auditor early.
For now, ask your team to explain what the container scan covers and what evidence they have for the rest of the environment. Agree who will handle the remaining review, corrections, and evidence before the audit. A clean scan alone cannot settle the outcome, but a clear record of the controls and follow-through gives the auditor something meaningful to evaluate.
Sources and further reading
AICPA SOC resources provide the SOC context. The Kubernetes multi-tenancy documentation explains shared environments and isolation. The Kubernetes security checklist provides technical review areas. These resources do not create a separate Kubernetes certification requirement for your SOC audit.