This article draws on insights originally shared by NeuVector CTO Gary Duan and Platform9 co-founder and CTO Roopak Parikh with TechRepublic.
Why Kubernetes Security Deserves Serious Attention
Kubernetes has become the de facto container orchestration platform across industries, running at scale in on-premises data centers, public clouds, and hybrid environments alike. That ubiquity creates a large and growing attack surface. Throughout 2019, a series of significant vulnerabilities were disclosed in Kubernetes itself—most notably a privilege escalation flaw discovered at the end of 2018, which allowed any authenticated user to establish a connection through the Kubernetes API server to a backend server and potentially escalate privileges.
As Gary Duan, CTO of NeuVector, put it: “Kubernetes has some basic security features—primarily around securing its own infrastructure. These include role-based access controls (RBACs), secrets management, and pod security policies. However, Kubernetes should not be deployed in business-critical environments or for applications that manage sensitive data without dedicated container security tools.”
The three tips below represent the core guidance Duan and Platform9’s Roopak Parikh offered for teams running Kubernetes at scale.
Tip 1: Enforce Role-Based Access Control (RBAC) and Network Policies
Security in a distributed system like Kubernetes requires multiple overlapping layers—there is no single control that covers everything. RBAC is the foundation, but it must be combined with network policies, authentication integration, and strong secrets management to be effective.
Connect Kubernetes to Your Enterprise Identity Provider
Parikh recommends integrating Kubernetes clusters with an enterprise authentication provider—such as an LDAP directory, Active Directory, or a single sign-on (SSO) platform. This ensures that access to cluster resources is governed by the same identity controls used elsewhere in the organization.
“A lot of times what we have seen is, you can secure all your systems all you want, but it’s also important to secure the keys—the passwords you use—with multi-factor authentication and use certificates to make sure people cannot get in through those easy doors,” Parikh said.
Assign Least-Privilege Roles and Isolate Namespaces
Each application or team should be scoped to specific namespaces, with RBAC policies that grant only the permissions required for that workload. Concretely, this means:
- Defining
RoleandClusterRoleobjects that grant the minimum necessary verbs (e.g.,get,list,watch) on only the required resources. - Binding those roles to specific service accounts, not to broad groups.
- Using
NetworkPolicyresources to restrict pod-to-pod and pod-to-external traffic to only what is explicitly needed. - Storing application credentials in Kubernetes
Secrets, and considering external secrets management systems (such as HashiCorp Vault) for sensitive production workloads.
Consider a Service Mesh for Encrypted Pod-to-Pod Communication
Duan noted that layering a service mesh such as Istio or Linkerd on top of Kubernetes can improve security by encrypting pod-to-pod communications via mutual TLS (mTLS). Service meshes also provide fine-grained traffic policies and observability. However, Duan cautioned that a service mesh introduces additional components—and therefore additional attack surface—that must themselves be secured and kept up to date.
Apply Cloud-Native Security Tools Across the Full Lifecycle
Traditional perimeter-based security tools are not designed for containerized environments. Duan recommended deploying cloud-native security tools that cover the entire application lifecycle, from the CI/CD pipeline through to runtime. For multi-cluster deployments spanning public and private clouds, federated policy management—where security policies are defined centrally and enforced across all clusters—becomes essential.
“True defense in depth is not possible without deep network visibility and protection, such as with a Layer 7 container firewall. Such a container-focused firewall will be able to detect and prevent network-based attacks, probes, scanning, breakouts, and lateral movement between containers using container micro-segmentation techniques.”
— Gary Duan, CTO, NeuVector
Tip 2: Continuously Scan for Insecure Code and Vulnerable Dependencies
Running workloads in containers does not automatically make them secure. Container images can bundle outdated OS packages, vulnerable language runtimes, or insecure application code. Parikh stressed that teams need tooling to detect these issues before and after deployment.
Scan Images at Build Time and in Registries
Integrate image vulnerability scanning into your CI/CD pipeline so that images are checked for known CVEs before they are pushed to a registry or deployed to a cluster. Many open-source and commercial tools exist for this purpose. Scans should also be run against images already sitting in your registry, since new vulnerabilities are disclosed continuously.
“You may want to scan it to figure out if there is insecure code or if you’re using an older version of a Python library. There are tools out there which can help you find out those details and give you a report on that. Based upon that, you can either deny or allow running those applications in the form of containment,” Parikh noted.
Declare Security Policy as Code
Duan highlighted that Kubernetes provides automation mechanisms that security tools should leverage. One practical approach is to declare security policy as code: capture the expected behavior of new services in a YAML manifest and deploy that policy as a Kubernetes custom resource definition (CRD). This makes security policy auditable, version-controlled, and reproducible—the same as application configuration.
Keep the Host OS and All Components Patched
The security of a Kubernetes cluster depends on the security of the nodes it runs on. Parikh emphasized that teams must keep the underlying operating system patched and use kernel security mechanisms (such as AppArmor or seccomp profiles) to restrict the capabilities available to containers. The principle of least privilege applies at every layer: the host OS, the container runtime, the Kubernetes control plane components, and the workloads themselves.
“You need to make sure that every component you install is patched and up to date.”
— Roopak Parikh, Co-founder and CTO, Platform9
Tip 3: Audit and Restrict Exposed Ports and API Endpoints
Every port and endpoint exposed by a Kubernetes cluster—whether via a LoadBalancer Service, a NodePort, an Ingress, or the Kubernetes API server itself—is a potential entry point for attackers. Parikh said Platform9 has observed real-world scanning activity against customer clusters where misconfigured or inadvertently exposed ports were probed by external parties.
“Someone figured out that something was exposed to the internet by other companies and we saw in the logs some people trying to probe our servers to figure out if those ports were open because insecure ports were open. Kubernetes itself has an API server, and in the past we have seen exposed ports,” Parikh said.
Harden the Kubernetes API Server
The API server is the central control point of any Kubernetes cluster and should never be exposed to the public internet without strict access controls. Ensure that:
- Anonymous authentication is disabled.
- The API server is accessible only over TLS with valid certificates.
- Access is restricted to known IP ranges using firewall rules or cloud security groups.
- Audit logging is enabled so that all API requests can be reviewed.
Review Every Externally Exposed Service
For each Service or Ingress that exposes a workload externally, teams should verify:
- Is this service intended to be public, or was it accidentally exposed?
- Is the exposure limited to the minimum necessary ports and protocols?
- If running in a public cloud, are the associated security groups or firewall rules as restrictive as they can be?
- Does the service require authentication before allowing access?
Automate Security Checks in the Pipeline
Duan recommended defining all integration points in the delivery pipeline where security checks should be automated, then building a roadmap to achieve complete security automation. Early steps might include triggering vulnerability scans on image builds and generating alerts on anomalous network activity. Over time, these checks can be expanded to cover admission control (using tools like OPA/Gatekeeper to reject non-compliant workloads at deploy time) and runtime behavioral monitoring.
Summary: A Layered Approach Is Non-Negotiable
Running Kubernetes safely at scale is not a single-control problem. The combination of RBAC and network policies, continuous image scanning, host-level hardening, and disciplined port management creates the overlapping layers of defense that are necessary in production environments handling sensitive workloads. As Duan summarized, traditional security tools were not built for containerized infrastructure—cloud-native tooling must be adopted across the full software lifecycle, from build to runtime.
As your cluster footprint grows across clouds and regions, invest in centralized, federated policy management so that security posture does not degrade with scale.