5 must-do security steps for Kubernetes

Kubernetes offers a wealth of security features and options, but implementing them can be complicated, and many of the default settings are not configured out of the box to a satisfactory level of enterprise-grade security standards.

So yes, there are a lot of options to avoid having your Kubernetes environment hacked. But I'm often asked: What are the main Kubernetes security best practices that you absolutely must get right, assuming you don’t have the time to do a CISSP certification and also become a full-time Kubernetes expert? Here are the five things you need to know.

State of Security Operations 2018

1. Use strong authentication

All Kubernetes components must be authenticated. These components typically service accounts or use x509 client certificates, and they're created automatically at cluster startup or are set up as part of the cluster installation. Failure to authenticate can make your entire Kubernetes environment susceptible to attack. In fact, this is how Tesla was breached recently, an incident that had intruders running crypto-mining containers in Tesla's Kubernetes cluster.

2. Enforce least privileges

If authentication is about who can access what, authorization is about what they can do once they access it, and least privileges is the principle that guides that. Ensure that RBAC is enabled to enforce a least-privileges model.

From K8S 1.9 onwards, there’s a pod security policy that allows you to restrict the behavior of a pod. Specifically, a pod security policy allows you to define a set of conditions that must be met before a pod is authorized to run. It’s a highly recommended practice to only allow what's needed for the pod to function and enforce a least-privileges model.

[Special Coverage: KubeCon/CloudNativeCon]

3. Segment your cluster


Segmentation is all about limiting the scope of a potential attack. If you suffer a breach, you can at least contain it to a subset of your deployment. There are several ways to do this.

Use K8S namespaces to create virtual clusters that are separated from one another, even when sharing the same infrastructure. Use K8S network policy to implement plug-ins such as Calico or Flannel to enforce rules and segment networking between pods. Finally, consider using a container-native firewall, which will actively block attempts to traverse the network, despite the logical segmentation.

4. Monitor your environment

Even if you take all of these steps to lock down your Kubernetes cluster, you may still experience breaches. You need to be able to detect and mitigate those as soon as possible.

At the most basic level, you can use K8S advanced auditing (in beta since K8S 1.7), with a webhook to an external analytics tool, for this purpose. But if you’re running production environments that are customer-facing or that handle sensitive data, use dedicated security tools that can detect policy violations and automatically prevent attacks from spreading.

5. Segregation of duties

This is often overlooked in cloud-native environments, but segregation of duties is essential for compliance, as well as basic security and defense against user errors or malicious insiders. The key point here is that your cluster administrator should not be the person overseeing security for the cluster. You can use K8S RBAC to define roles and monitor changes to that policy.

Finally, I’d be remiss if I didn’t mention the CIS Kubernetes Benchmark, which includes a long list of best-practice checks to perform on your nodes. Luckily, there’s an open-source tool, kube-bench, that makes it easy to check your cluster against the CIS benchmark. I recommend using it to baseline your security posture.

For more on Kubernetes security, come see my Lightning Talk: Why you Should Really Pay Attention to K8S Security Best Practices" at KubeCon/CloudNativeCon, which runs May 2-4 in Copenhagen. TechBeacon readers receive a 20% discount when they enter code KCCNEUTB.

State of Security Operations 2018