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.
- 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:
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.
- Read The Ultimate Guide to Container Orchestrators. If you’re struggling to identify the differences between container orchestrators, and decide which one is the best fit for your needs, this article is for you.
- See Kubernetes + Twistlock key security features and hear our CTO, John Morello, discuss how Twistlock works with Kubernetes and any other orchestration tool.
- Check it out – Just released: Kubernetes CIS Benchmark for 1.6
- View our collection of Kubernetes related posts
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Your Firewall’s Role in Cloud-Native Security
We live in the cloud-native era. That means the firewall strategy that...
Compliance, Microservices and Your Application
Compliance in modern applications that leverage containers, serverless...
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...