Kubernetes Security Audits: What Admins Need to Know—and Do

Enterprise organizations across nearly every vertical—financial services, healthcare, government, telecommunications—are running production workloads on Kubernetes. As the platform has matured, so has the scrutiny applied to its security posture. The Cloud Native Computing Foundation (CNCF) responded by commissioning a third-party security audit of the Kubernetes project and open-sourcing the results, giving the entire community visibility into findings and recommended mitigations.

This article summarizes the key findings and translates them into actionable steps for cluster administrators.

Audit Findings: 37 Issues Identified

Trail of Bits, one of the firms that performed the audit, produced a final report, a threat model, and a white paper containing hardening recommendations. The final report identified 37 issues with the following severity breakdown:

• High severity: 5 issues
• Medium severity: 17 issues
• Low severity: 8 issues
• Informational: 7 issues

It is important to understand the nature of these findings. Although the report uses the word “vulnerabilities,” most of the 37 issues are not assigned CVEs. The majority represent hardening opportunities and architectural improvements rather than exploitable bugs—though some general weaknesses could lead to CVEs in specific deployment scenarios. The practical takeaway for admins is that a significant portion of the risk can be reduced through configuration, not just patches.

Securing the Control Plane

The control plane is the most critical part of any Kubernetes cluster. The Kubernetes API server and the etcd key-value store—which holds the desired state of every workload on the cluster—must both be locked down. Standard security principles apply directly here:

• Least privilege via RBAC: Use Kubernetes Role-Based Access Control (RBAC) to grant users and service accounts only the permissions they need. Avoid cluster-admin bindings for day-to-day operations.
• Encrypt API server traffic: All communication to and from the API server should use TLS. This is the default for managed clusters but must be verified for self-hosted deployments.
• Encrypt etcd at rest: Enable encryption of secret data stored in etcd. This requires Kubernetes 1.13 or later and etcd v3 or later. Without encryption at rest, any actor with access to etcd storage has access to all cluster secrets in plaintext.

Staying reasonably current with Kubernetes releases is also a security discipline. Enterprise organizations cannot always track the upstream release cycle immediately, but teams should monitor upstream releases and evaluate each one for critical vulnerability fixes or security-relevant feature additions. Running a significantly outdated version means missing patches for known issues.

Networking Security

The audit found networking security to be weak on several fronts. Kubernetes offers a number of mechanisms that cluster admins can use to harden network-level controls.

Network Policies

Kubernetes NetworkPolicy resources let you define which pods can communicate with each other and with external endpoints. Without NetworkPolicies in place, all pods in a cluster can communicate freely—a significant lateral-movement risk. Admins should define NetworkPolicies for every namespace, starting with a default-deny posture and explicitly allowing only required traffic flows.

Note that NetworkPolicies are enforced by the CNI plugin, not by Kubernetes itself. Your chosen CNI must support NetworkPolicy enforcement (for example, Calico, Cilium, or Weave Net). Flannel alone does not enforce NetworkPolicies.

Ingress and Egress Controls

To secure egress traffic for services deployed on Kubernetes, admins can allocate static IP addresses to specific nodes at the host level and configure per-project egress IPs. This ensures that traffic leaving a pod originates from a known, pre-approved IP address. External systems such as databases can then allowlist those IPs, so only authorized pods can reach sensitive back-end services via an egress router.

Istio Service Mesh

Istio addresses several networking security gaps by injecting an Envoy sidecar proxy into every pod. All traffic entering or leaving a pod is routed through that proxy, making it impossible for workloads to bypass traffic controls. Istio uses mutual TLS (mTLS) between Envoy instances across the cluster, which means:

• Pod-to-pod traffic is encrypted in transit.
• Both sides of a connection authenticate each other, preventing spoofing.
• Traffic is observable through Istio’s telemetry stack.

Adopting a service mesh adds operational complexity, but it directly addresses the audit’s finding that inter-pod traffic is often unencrypted and unauthenticated by default.

Multus CNI for Network Segmentation

Multus is a “meta-plugin” CNI that enables multiple network interfaces per pod, with a different CNI assigned to each interface. One particularly relevant use case from a security perspective is separating the control plane from the data plane: the API server communicates with a pod over one dedicated network interface, while all other pod-to-pod traffic runs on a separate interface. This limits the blast radius of a network-level compromise.

Protecting Host Systems

Containers share a kernel with their host. If the container runtime or a workload is compromised, the host kernel is the last line of defense. Several Linux and Kubernetes mechanisms help protect at this layer.

SELinux

SELinux provides mandatory access control (MAC) at the kernel level, governing what every process can access regardless of its Unix permissions. It has been credited with mitigating container-escape vulnerabilities including CVE-2016-9962 and CVE-2019-5736. Admins should ensure SELinux is enabled and enforcing on all Kubernetes nodes, not just permissive mode.

Pod Security Policies (PSPs)

Pod Security Policies provide a cluster-level admission control mechanism that enforces security constraints on pod specifications before they are scheduled. PSPs allow admins to:

• Block privileged containers.
• Restrict access to host namespaces and host network/ports.
• Enforce specific user and group IDs.
• Mandate SELinux profiles and seccomp profiles.

Note: Pod Security Policies were deprecated in Kubernetes 1.21 and removed in 1.25. If you are running Kubernetes 1.25 or later, use the built-in Pod Security Admission controller or a policy engine such as OPA Gatekeeper or Kyverno to enforce equivalent controls.

Secure Computing Mode (seccomp)

Seccomp is a Linux kernel feature that restricts which system calls a process is allowed to make. By applying seccomp profiles to pods—either through PSPs (on older clusters) or through the securityContext.seccompProfile field (Kubernetes 1.19+)—admins can significantly reduce the kernel attack surface available to a compromised container. As of Kubernetes 1.27, the RuntimeDefault seccomp profile can be enabled by default at the kubelet level.

Logging and Audit Trails

Comprehensive logging is a foundational security control. Cluster admins should:

• Enable Kubernetes API server audit logging and define a policy that captures at minimum all write operations and sensitive read operations.
• Enable the Linux auditd daemon on all nodes to capture system-level events.
• Deploy a centralized logging stack within the cluster (for example, a Fluentd or Fluent Bit daemonset shipping to an Elasticsearch or equivalent backend).
• Forward logs to an external SIEM or log management platform that is outside the cluster. This protects log integrity—an attacker who compromises the cluster cannot easily tamper with logs stored externally.

Be Proactive: A Security Mindset for Kubernetes Admins

The CNCF audit is a positive signal for the ecosystem. By commissioning an independent third-party review and publishing the results openly, the Kubernetes community demonstrated a commitment to transparency and continuous improvement. Open publication allows the community to collaboratively respond: contributors can work on code improvements, and operators have clear visibility into risk areas so they can prioritize hardening efforts.

Several practical principles emerge from the audit findings:

• Configuration matters as much as code. Many of the 37 issues are addressable through proper configuration rather than waiting for upstream code fixes.
• Defense in depth is essential. No single control is sufficient. Network policies, mTLS, SELinux, seccomp, RBAC, and audit logging each address different threat vectors and together create overlapping layers of protection.
• Keep up with releases. Vulnerability fixes and security feature additions appear in every Kubernetes release. Staying within a supported version range is a security requirement, not just an operational preference.
• Test your posture. Tools such as kube-bench (which checks cluster configuration against CIS Kubernetes Benchmarks) can help identify gaps before an auditor does.

The default security posture of Kubernetes continues to improve with each release. But organizations should not wait for defaults to catch up. The controls described above are available today and, when properly applied, can substantially reduce the risk profile of any Kubernetes deployment.

This article is based on findings from the CNCF-commissioned Kubernetes security audit performed by Trail of Bits. The original reporting appeared on TechBeacon.