Kubernetes and Container Security Testing: What It Covers

Tests usually begin from one of two places: an attacker who has remote code execution in one container of an application, or a developer account with limited access. The tester asks what that position can reach next.

From a shell in an application container, the tester checks what the pod's service account may do:

$ kubectl auth can-i --list
Resources                          Non-Resource URLs   Resource Names   Verbs
*.*                                []                  []               [*]

The account can do anything in the cluster. An application pod has been given cluster-admin, a common shortcut taken during a migration. With it, the tester can read secrets from every namespace and start a new pod on any node. The report shows the command, the role binding that grants this and the fix: a role with only the verbs and resources the application needs, in its own namespace.

• Service accounts with far more rights than the workload needs, and tokens mounted into pods that never call the API.
• Privileged pods, hostPath mounts and access to the container runtime socket, which can give control of the whole node.
• Secrets stored as plain environment variables or committed to deployment files.
• No network policies, so any pod can reach every other pod, the database and the metadata service.
• The dashboard, the kubelet or the API server reachable from the internet.
• Images pulled from public registries with no pinning or scanning.

• List the cluster role bindings and look for subjects that are not people you recognize: kubectl get clusterrolebindings -o wide.
• From inside a pod, run kubectl auth can-i --list with the pod's own account.
• List pods that run privileged or with a host path, and ask why each one needs it.
• Check whether a default-deny network policy exists in each namespace.
• Find out how the cloud account gives rights to pods, and whether pods can reach the metadata address.

apiVersion: v1
kind: ServiceAccount
metadata: { name: orders-api }
automountServiceAccountToken: false     # most pods never call the API

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: orders }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]       # then allow only the flows you need

Apply the Pod Security Standards at the restricted level to namespaces that can take it, keep roles narrow, store secrets in a dedicated secrets manager or encrypt them at rest, scan and sign images, and give pods their cloud permissions one role per workload. Test in a staging cluster first, because tightening network rules can break traffic nobody wrote down.

A Kubernetes test is scoped with a cloud security assessment, so that the account and the cluster are tested together. See also SSRF and cloud metadata.

To plan a test for your own systems, request a scoping call, or download the pre-test checklist and scoping questionnaire.

Links checked on 5 November 2026.

• Kubernetes documentation, Security concepts, the security model
• Kubernetes documentation, Pod Security Standards, privileged, baseline and restricted
• Center for Internet Security, CIS Kubernetes Benchmark, configuration checks