Container Security

Kubernetes Security: Kubernetes Clusters Best Practices

Kubernetes Container Security with Twistlock

Kubernetes is a multi-host management and orchestration layer that is designed to work with containers. Securing a Kubernetes cluster will entail everything we would do to protect a single container host with the addition of strategies that are specific to the orchestration and management functionality.

The high level strategies for securing web applications remain the same and can be boiled down to: Trust your sources, Principle of least privilege, and minimize attack surfaces. These strategies all work together both to form our Kubernetes Security Best Practices, and will ultimately reduce the likelihood of an attack as well as contain any attacks and minimize their damage potential.

In this post, I’ll highlight Kubernetes security best practices with a focus on orchestration. I will also show how Twistlock can handle many aspects of keeping the cluster secure. I will be using Kubernetes and container terminology interchangeably, (e.g. host / node and container / pod). The terms aren’t identical but for the purposes of this guide are close enough.

Network Segmentation & Security

Kubernetes lets us orchestrate a dynamic network with a topology that can shift and change. It also has tools to let us ensure the different parts of the network are only exposed where necessary, helping us with both Principle of least privilege as well as reducing attack surfaces.

We can achieve network segmentation using these tools and some planning. This is similar to the security benefits we get “for free” when we plan our containers to be single purpose and immutable. By leveraging the networking labels, rules, and segmentation we can benefit from added security just by using Kubernetes as it is meant to be used.

Kubernetes lets us define Namespaces and then configure whitelists of allowed communication between various resources within them. A Network Policy lets us define which pod to pod communication in allowed within a cluster.

Unified workflow through kubectl

There are many benefits to having our administration and management in our cluster all go through kubectl, instead of SSHing into nodes and / or pods — this lets us benefit from a single source of authorization and permissions, logging, and monitoring. It also reduces the attack surfaces by not exposing SSH ports needlessly.

This also means we get the benefit of the Kubernetes cluster wide logging. The aggregation of activity distributed between the nodes and pods can be monitored through a single funnel which is a huge advantage when deploying and securing a complex containerized application.

Principle of least privilege

Administrators can ensure the Principle of least privilege leveraging built in OS security features. Kubernetes security lets us define a Security Context that ensures our containers and pods are running with the correct user and OS level privileges. It is also possible to enforce cluster wide rules around security contexts using a Security Policy, or a Security Context Constraint in OpenShift.

This makes it easy to know that there are no pods in our cluster that are running with a root user, for example.

Securing Kubernetes Clusters With Twistlock

Securing an orchestrated cluster means first and foremost securing the individual containers that compose it. Adding a Twistlock Defender to each host in our cluster will help us Trust Our Sources and ensure that our containers and images are protected: during deployment as part of CI workflow and on an ongoing basis as they are running.

Twistlock will:

Ensure we don’t deploy any images or containers with known vulnerabilities

Enforce security policies based on CIS guidelines and regulatory requirements

Twistlock Runtime monitoring for suspicious activity such as unknown processes or system calls

The Twistlock Defender can be installed in a Kubernetes cluster using Daemon Sets to ensure all of the hosts are protected:

Closing Thoughts

Securing a Kubernetes cluster is pretty similar to securing a non-orchestrated containerized application. The main differences involve taking the dynamic nature of the cluster into account and using the building blocks Kubernetes provides to create well defined roles and boundaries within our cluster. Look for more Kubernetes Security Best Practices coming soon! Subscribe to our newsletter below to get updates on our latest blog posts.