Kubernetes Security Review

The problem

Kubernetes is secure by configuration, not by default. A cluster that passes a vulnerability scan can still hand an attacker the entire estate, because the interesting weaknesses are not missing patches. They are a service account with cluster-admin that nobody remembers granting, a namespace with no network policy in a cluster where the default is allow-all, a workload running privileged because it was the fastest way past an error two years ago, and an admission controller that logs violations instead of blocking them.

Most organizations discover this in one of two ways. Either an auditor asks for evidence that the clusters meet a recognised hardening standard and nobody can produce it, or someone gets a foothold in one workload and it turns out that lateral movement was never actually constrained.

The review exists to find those things while they are still cheap.

What we review

• Identity and RBAC. Role and binding analysis, cluster-admin sprawl, over-permissive service accounts, token exposure, and what each identity could reach if it were compromised

• Workload hardening. Pod Security Standards conformance, privileged containers, host namespace and host path use, capabilities, and the gap between what workloads request and what they need

• Network posture. Whether a default-deny position exists, how segmentation is enforced between namespaces and tenants, egress control, and what an attacker in one pod can reach from there

• Supply chain. Image provenance, registry trust, signature verification, admission control, and whether policy is enforcing or advisory

• Secrets handling. Encryption at rest, external secret store integration, secrets in manifests and environment variables, and mount patterns

• Control plane. API server exposure, authentication paths, etcd encryption, audit logging configuration, and whether the audit trail would answer a real question

• Multi-tenancy boundaries. Where the isolation claim is namespace-level, where it is stronger, and whether it matches what the workloads on those clusters actually require

• Runtime detection. What is monitored, what would be noticed, and how long it would take

We assess against the CIS Kubernetes Benchmark and the NSA and CISA Kubernetes Hardening Guidance, because those are the standards your auditors and tenders reference. We use automated tooling for coverage and manual review for the findings that tooling cannot see, which in our experience are the ones that matter.

How it runs

This is a review, not a penetration test. We work from read-only access and configuration analysis rather than exploitation, which is faster, safer against production, and finds a different and usually larger set of problems. Where a finding warrants proof, we say so and scope it separately.

What you get

• Prioritised findings, each with the exposure it creates, the evidence behind it, and a specific remediation

• Benchmark conformance position against CIS and NSA/CISA guidance, in a form you can hand to an auditor

• Attack path narratives: what a compromised workload could reach, and where that stops

• A remediation plan sequenced by risk reduction per unit of effort, separating what to fix this month from what belongs in a platform roadmap

• A technical readout for your engineers and a short executive summary for people who will fund the fixes

Who it is for

Organizations running production workloads on Kubernetes, particularly where clusters are multi-tenant, where a regulatory obligation applies, or where the platform grew faster than the security review cycle did.

What happens next

Findings usually split in two. The immediate fixes your team can take on directly, and the structural ones (enforcement instead of advisory policy, tenancy that holds, guardrails inside the golden path) that belong in platform work. Where that is the case, the Platform Engineering Maturity Assessment is the natural next step, and the review’s findings feed straight into it.