When it comes to security, there is a lot that Kubernetes does. There is also a lot that it doesn’t do.
To secure Kubernetes effectively for real-world deployment, you must understand which built-in security features Kubernetes offers and which it doesn’t, and how to leverage Kubernetes’s security capabilities at scale.
Below, we walk through Kubernetes’s security architecture and discuss best practices for securing production Kubernetes deployments.
Kubernetes Architecture: components overview
At first glance, Kubernetes security might seem simple. But Kubernetes is a complex tool, and a Kubernetes deployment involves many layers and moving parts. Securing Kubernetes is actually a bit complicated.
A Kubernetes deployment consists of many different components, including:
- The Kubernetes master
- The Kubernetes nodes
- The server that hosts Kubernetes
- The container runtime you use with Kubernetes
- Networking and transport layers within your cluster
- Any interface, logging, monitoring and other tools you use in conjunction with Kubernetes
- The applications that run inside containers hosted on Kubernetes
Securing Kubernetes requires you to address the security challenges associated with each of these components.
Kubernetes Security: Built-in Features
Fortunately, Kubernetes offers several built-in security features to help secure the components described above.
Role-based access control, or RBAC, lets you specify which users are able to perform certain actions (like reading pods) using the Kubernetes API. The access policies you specify can be applied within a given namespace, or (if you define a ClusterRole) across multiple namespaces.
Pod security policies
Think of Kubernetes pod security policies as sort of the opposite of RBAC policies. While RBAC lets you control which actions certain users can perform on pods (or other resources), pod security policies are used to restrict the actions that pods are allowed to perform. You can create pod security policies that do things like prevent containers from running as root, or disallow a pod to share the process ID namespace with its host.
Kubernetes allows you to define a Network policy to control what traffic is allowed to flow between different pods and endpoints in your cluster.
Network policies aren’t designed primarily as a security tool; they are mainly a way to manage network traffic and avoid unnecessary network load. However, because they allow you to block traffic to or from certain pods or endpoints, they can essentially function as a sort of firewall if you want them to. Network policies are a handy way to help lock down the networks inside your cluster in order to reduce security risks associated with the network.
If you are running an application on Kubernetes that needs to access secrets (like passwords or an SSH key), you can keep those secrets secure by using Kubernetes’s built-in secrets management framework. To do this, you use the kubectl command to translate your secret information into a special object (which Kubernetes refers to as a Secret, with a capital S) that you can later make accessible to your pods.
Thanks to Secrets, you don’t have to do insanely insecure things, like store passwords as plain text files inside your container images.
What Kubernetes doesn’t secure (on its own)
Although the features described earlier address some of the security needs of a Kubernetes deployment, they don’t cover everything. There are a number of notable gaps, including:
- Host security: Kubernetes host security is on you. Kubernetes does nothing to keep host servers secure. See our tutorial to learn how SELinux protects your Kubernetes cluster at the host level.
- Images: Your application is only as secure as the images you use to run it. Kubernetes won’t check your images for insecure code or other vulnerabilities.
- Container runtime: No matter which runtime you choose to use with Kubernetes, Kubernetes won’t do anything to detect breaches that exploit the runtime or known security vulnerabilities within the runtime.
You’ll either have to manage these Kubernetes security needs manually or use a dedicated security tool that provides these features.
Keeping Kubernetes secure at scale
It’s easy to talk about Kubernetes security features and best practices when you’re dealing with an experimental cluster or a small-scale deployment where you can manage everything by hand.
But what if you have a large, production-grade Kubernetes deployment that comprises dozens of pods (or more) spread across a sprawling infrastructure? In that environment, it’s critical to streamline your approach to Kubernetes security in order to keep it manageable and consistent.
The following strategies can help:
- Focus on reusable policies: You don’t want to have to recreate or update RBAC or pod security policy configurations every time your cluster changes or you redeploy an app. Strive to write policies that can be reused indefinitely.
- Write broad policies: For efficiency’s sake, it’s often preferable to write a policy that applies to your entire cluster rather than one that applies only to one specific resource. You can’t do this in all situations, of course, but when possible, write policies that are as broad as possible.
- Secure your images and hosts: As we noted, Kubernetes itself doesn’t do anything to help secure images or hosts. Fortunately, many third-party tools do. Use frameworks like SELinux or AppArmor to harden your hosts, and make sure you scan your container registries for known vulnerabilities.
- Securing communications across various Kubernetes services: Since Kubernetes is API drive, you should specify who can access the cluster as a security measure. This is done using Transport Layer Security (TLS) and Certification management between the Kubernetes api-server, etcd, kubelet, and other services.
- Consider a managed Kubernetes service: Although the security services provided by Managed Kubernetes platforms vary from vendor to vendor, most managed offerings will provide at least some security support and reduce the amount of security considerations that you need to manage yourself. Some of these solutions, like our own Platform9 Managed Kubernetes, not only provide RBAC and security management, but also instant security patches and upgrades in cases where you need to upgrade your Kubernetes infrastructure across all clusters.
Like most things that involve Kubernetes, Kubernetes security is a complex, multi-faceted discipline. Fortunately, there is no shortage of solutions and best practices for helping to secure Kubernetes deployments, even at scale. Once you wrap your mind around what is available, keeping Kubernetes secure, while still not simple, is much less difficult than you might think.
Latest posts by Platform9 (see all)
- Kubernetes Security: What (and What Not) to Expect - October 14, 2019
- Kubernetes Service Discovery: Principles in Practice - October 7, 2019
- Kubernetes Multi-Tenancy Best Practices - October 1, 2019