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.
What Service Meshes Mean for Enterprise Security
Service meshes: Heard of them? By now, you may have. Service meshes ar...
The Business Value of Cloud Native Cybersecurity
“Software is eating the world,” Marc Andreessen wrote in 2011. Fiv...
How To Operationalize DevSecOps Practices
DevSecOps is not as much about the tools as it is about the people and...
Enhanced Visibility: Container Vulnerability Management from Build to Runtime
Earlier this year, I was at a large industry event and ended up speaki...
How Serverless Changes the Security Paradigm
Serverless architectures are quickly becoming a major technology withi...