Kubernetes Security Assessment

It evaluates a Kubernetes cluster for security weaknesses — RBAC misconfiguration and privilege escalation, insecure workloads and missing admission control, open network policies, secrets exposure, and an under-hardened control plane — measured against the CIS Kubernetes Benchmark, the NSA/CISA hardening guidance, and the OWASP Kubernetes Top 10, with each finding proven and rated.

Primarily the CIS Kubernetes Benchmark for configuration hardening, the NSA/CISA Kubernetes Hardening Guidance for the control plane and workloads, and the OWASP Kubernetes Top 10 for the common risk categories. We also use the Pod Security Standards as the baseline for workload settings.

Usually a read-only, scoped service account and its kubeconfig, so we can inventory and review without changing anything. For an assumed-breach test of lateral movement and escape, a foothold pod in the cluster is ideal. We agree the scope, the namespaces in play, and anything to avoid before we begin.

Both. On a managed cluster the provider hardens the control plane under a shared-responsibility model, so we focus on what remains yours — RBAC, workloads, network policies, secrets, and node configuration; on a self-managed cluster we also review the API server, etcd, and kubelet directly.

RBAC decides which identity may perform which action on which resource. Privilege escalation is when an over-broad role or binding — a service account that can create pods, read secrets, or impersonate others — lets a low-privilege foothold reach cluster-admin. It matters because it turns a single compromised pod into control of the whole cluster, and it is invisible to a scan that only checks settings in isolation.

From a foothold pod we check whether network policies actually restrict pod-to-pod and namespace-to-namespace traffic — by default Kubernetes allows all of it — and whether reachable services, service-account tokens, or the cloud metadata endpoint let us move further or escalate. The result is the real blast radius of one compromised pod.

The review and mapping are read-only and safe. Active tests — escape attempts, lateral movement — are agreed in advance and run carefully; we prefer a staging cluster that mirrors production, and when we must test production we set limits and keep a contact on your side to pause at once if anything looks wrong.

Each finding gets a CVSS score for a common baseline, adjusted by the real impact in your cluster — what an attacker reaches, how easily, and whether it leads to cluster-admin or data. That is why two issues with the same CVSS can be prioritized differently.

Yes. After you remediate, we re-test the reported findings to confirm each fix holds and did not open a new gap, and we update their status in the report.

It depends on the number of clusters, namespaces, and workloads and on how much of the stack is yours to harden; a typical assessment runs about two to four weeks. We give a firm estimate after scoping.