Kubernetes has become the widespread standard for container orchestration at enterprise scale. But with that commonality comes a growing and often underestimated attack surface.
Misconfigurations, over-permissioned workloads, exposed dashboards, and poorly managed secrets have all led to significant security breaches for organisations, most of which were entirely preventable had teams behaved more proactively.
This is why Kubernetes security assessments are so beneficial when carried out before your team pushes to production. In many cases, proactivity is the difference between catching a critical misconfiguration in a controlled environment and discovering it through a breach. Not ideal.
This technical guide walks through what a thorough pre-production Kubernetes security assessment looks like, why it matters, and the key network security measures your team should be enforcing.
Why Are Kubernetes Misconfiguration Risks So Significant?
Unlike traditional infrastructure, Kubernetes environments are highly dynamic.
Workloads fluctuate, role-based access control (RBAC) policies evolve, and clusters are frequently modified by multiple teams simultaneously.
This constantly changing pace creates an opportunity for Kubernetes misconfiguration and network security risks to creep in undetected. Security policies are non-negotiable when there are so many environment variables.
Common sources of Kubernetes security vulnerabilities
- Default Kubernetes configurations that were never hardened
- Overly permissive RBACs were applied for convenience and never revised, giving attackers greater escalation once they achieve unauthenticated access
- Improper data encryption
- Container images running as root without necessity
- Exposed Kubernetes API access with insufficient access controls and authentication mechanisms
- Weak or absent network policies between pods and network namespaces
The consequences can be severe: a compromised pod with excessive privileges can become the catalyst for lateral movement across an entire cluster. Sensitive data can also be exfiltrated through misconfigured egress rules, or secrets can be read in plain text from environment variables or etcd.
Remediating these issues after a production deployment- or worse, after a breach- is costly, disruptive, and can damage your organisation’s reputation.
A pre-production assessment allows security teams to surface and fix these weaknesses before attackers gain access and transform vulnerabilities into severe risks.
What Does a Kubernetes Security Assessment Cover?
A thorough Kubernetes security assessment that enterprise teams should conduct before going live covers several distinct layers. Each one addresses a different dimension of cluster security.
1. API Server and Control Plane Hardening
The Kubernetes API server is the central point of control for the entire cluster. If it is exposed or misconfigured, everything else is at risk.
Key checks include:
- Is anonymous authentication disabled?
- Is the API server accessible only from authorised networks or via a private endpoint?
- Is role-based access control (RBAC) enabled and correctly enforced?
- Are audit logs enabled and being captured to a tamper-resistant destination?
- Is the etcd datastore encrypted at rest and accessible only to the control plane?
These are foundational: if the control plane is not secure, no number of application-level controls will adequately protect the environment.
2. Kubernetes Role-Based Access Control Security
Role-Based Access Control is one of the most powerful and most frequently misconfigured aspects of a Kubernetes environment. Poor RBAC hygiene can allow a compromised service account to escalate privileges, access secrets across namespaces, or modify cluster-wide resources.
Your assessment should evaluate:
- Whether any service accounts have been granted cluster-admin or wildcard permissions unnecessarily
- Whether workload service accounts are scoped with least-privilege principles applied
- Whether role bindings are regularly reviewed and have clear ownership
- Whether default service account tokens are mounted where they are not required
- Avoid broad roles and enforce the principle of least privilege.
A common finding during Kubernetes security assessments is that RBAC policies were written permissively during development and never tightened or revisited by teams before production. Identifying and correcting this before go-live is a significant risk reduction.
3. Pod Security and Workload Configuration
Individual workloads carry their own security profile, and insecure pod configurations are one of the most prevalent Kubernetes misconfiguration risks seen in enterprise environments.
Evaluate whether workloads:
- Run as non-root users with the lowest necessary UID
- Drop unnecessary Linux capabilities
- Use read-only root filesystems where workloads allow it
- Avoid the use of privileged: true unless strictly required
- Enforce resource limits to mitigate denial-of-service risks
Kubernetes Pod Security Admission (which replaced the deprecated PodSecurityPolicy) should be configured to enforce a suitable security standard (baseline or restricted) at the namespace level.
If a workload can’t meet these standards, it should be documented and risk-accepted with appropriate mitigating controls, so that teams can better respond to any potential issues.
4. Kubernetes Secrets Management
Kubernetes secrets data management is one of the most overlooked areas of cluster security. By default, Kubernetes secrets are stored in etcd as base64-encoded values: they are not encrypted unless you have explicitly configured encryption at rest.
A pre-production assessment should confirm:
- That encryption for etcd is s actually enabled to encrypt secrets.
- That etcd encryption at rest is enabled with a strong encryption provider
- That secrets are not being passed as environment variables in pod specs, where they can be exposed through logs, or kubectl describe
- Whether an external secrets management solution (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) is in use and correctly integrated
- Secret access is scoped by namespace and service account, not granted cluster-wide
Exposed credentials are one of the leading causes of cloud and container-related breaches and security incidents. Getting Kubernetes secrets management right before production significantly reduces this risk and sets you up for more secure post-production deployment.
5. Network Policies and Egress Controls
By default, Kubernetes allows all pod-to-pod communication within a cluster. Without network policies, a compromised workload can communicate freely with any other pod — including those in sensitive namespaces.
Your assessment should verify:
- Whether default-deny network policies are in place at the namespace level
- Whether only necessary ingress and egress traffic is explicitly permitted
- Whether sensitive workloads (such as databases) are isolated from application-facing pods
- Whether external DNS and outbound network traffic are restricted to known destinations
Uncontrolled egress is a significant enabler of data exfiltration. A compromised container with unrestricted outbound access can silently exfiltrate data over a number of channels before detection.
6. Container Image Security and Supply Chain Risks
The container images running in your cluster are a significant part of your attack surface. Images built on unpatched base images, or pulled from untrusted registries, introduce vulnerabilities before your application code has been evaluated at all.
Assess whether:
- Images are scanned for known CVEs as part of the CI/CD pipeline
- Only images from trusted, internal registries can be deployed (enforced via admission controllers)
- Image signing and verification are in place to prevent tampered images from running
- Base images are minimal and actively maintained
7. Controlling Access and Policy Enforcement
Admission controllers act as gatekeepers, intercepting API requests before objects are persisted to the cluster. They are one of the most effective mechanisms for preventing insecure configurations from entering production in the first place.
Your assessment should check whether:
- Admission controllers such as OPA Gatekeeper or Kyverno are deployed and enforcing policies
- Policies prevent the creation of privileged containers, containers without resource limits, or workloads without required labels
- Webhooks are secured and validated to prevent bypass
How to Secure Kubernetes Before Deployment: A Best Practice Approach
Knowing what to assess is one thing; having an efficient, repeatable process is another. With that in mind, here’s a practical approach for teams preparing for a pre-production security review.
Start with a CIS Kubernetes Benchmark scan. Tools such as kube-bench automate the checking of cluster configuration against CIS benchmarks. This gives a fast, structured baseline of findings prioritised by severity.
Conduct a manual RBAC and secrets audit. Automated tools will surface many issues, but a manual review of role bindings, service account permissions, and secrets configurations provides depth that scanners often miss. Kubernetes audit logs are essential in sustaining good security and also quickly recognising anything unusual.
Run a dedicated penetration test. A Kubernetes-specific penetration test simulates real-world adversary techniques, including container breakout attempts, RBAC escalation paths, and lateral movement across namespaces. This goes beyond configuration review to actively probe whether security controls hold up under attack conditions.
Document and risk-accept residual findings. Not all findings will be immediately remediated. A risk register with clearly owned items, timelines, and mitigating controls ensures that residual risk is visible and managed rather than forgotten.
The Role of Penetration Testing in Kubernetes Security Assessment
Automated scanning and configuration review are essential, but they are not thorough enough on their own. Penetration testing adds the adversarial, real-world perspective that configuration tools simply cannot replicate when it comes to Kubernetes security.
For example, a skilled penetration tester will probe whether a misconfigured RBAC role can be exploited to access another namespace, whether a privileged container can be used to escape to the host node, and whether secrets exposed through a vulnerable application can be leveraged to move laterally across the cluster.
These attack chains are the ones that result in real-world breaches, and they require human expertise, business logic experience, and creativity to uncover.
Organisations that include penetration testing as part of their pre-production Kubernetes security assessment process guarantee a stronger security posture than those that rely on scanning alone.
Manage sensitive data safely and securely with OnSecurity’s platform-based penetration testing. Challenge the security of your secret data, cloud environments, and Kubernetes infrastructure with our blend of expert, human-led testing and automated, time-efficient reporting.
