With dozens of Kubernetes distributions available, deploying Kubernetes is easier than ever.
What can be trickier is keeping Kubernetes secure. Despite what you might think, many Kubernetes distributions are not as secure as they could be out of the box. And even if they are, there’s always more you can do to improve security.
That’s why it’s essential to stay on top of Kubernetes security best practices. Below, we take a look at some of the key considerations when it comes to Kubernetes security. This isn’t an exhaustive Kubernetes security guide, but it emphasizes core essentials that can help you take an out-of-the-box Kubernetes deployment and make it more secure.
Secure the Kubernetes host
Kubernetes security starts on the host system. Whichever operating system you’re using to host your Kubernetes environment, be sure that it is as secure as it can be.
We won’t go into the details of operating system security here, but at a minimum, they should involve:
- Stripping out unnecessary components of the operating system. Any app or library that you don’t actually need to host Kubernetes is just an unnecessary security risk.
- Using frameworks like AppArmor or SELinux to help harden the system against attack.
- Controlling physical and virtual access to the system.
If you are using a managed Kubernetes service, such as one hosted on a public cloud, in that case, your control over the host operating system is typically very limited, and you can’t do much to harden it. You can, however, take advantage of cloud-based security tools, like your cloud provider’s IAM framework, to help mitigate the risk of attacks.
Enable and use pod security policies
Pod security policies are a tremendously useful security feature in Kubernetes. In fact, they’re one of the only major security features that are built into Kubernetes.
Pod security policies allow you to set basic security rules that Kubernetes automatically enforces across all pods within the Kubernetes cluster. You can do things like preventing containers from running in privileged mode or requiring SELinux.
Currently, Kubernetes pod security policies remain relatively basic and limited in what they can control. You certainly shouldn’t think of them as the be-all, end-all of Kubernetes security. But they are one helpful component.
You should therefore make sure that pod security policies are enabled in your Kubernetes deployment (it may surprise you to know that they are often not enabled by default, depending on which distribution you use). You’ll also want to write policies to enforce basic security essentials.
Enable and use RBAC
Role-based access control, or RBAC, is another basic and essential security feature. It lets you apply access-control policies to the Kubernetes API in the same way that pod security policies do for your cluster of pods.
You might assume that RBAC would be enabled by default in all Kubernetes deployments. But it’s not. So make sure you enable RBAC by starting your API server with the –authorization-mode=RBAC flag.
Then, configure roles appropriately so that users can access only the specific resources they need. This is much safer than giving full cluster control to any authenticated user.
Leverage Kubernetes namespaces
Kubernetes lets you configure namespaces, which are virtual clusters running within your physical Kubernetes cluster.
Namespaces are useful for a variety of purposes beyond security. They help to simplify cluster management by making it easier to apply certain policies to some parts of the cluster without affecting others.
But don’t make the mistake of assuming that the point of namespaces is just to help with cluster management. They also play a critical security role because they allow you to do things like isolate workloads (thereby mitigating the risk of the escalation of a security breach to the whole cluster) and establishing resource quotas (which can help to limit the amount of harm that an attacker can cause by taking control of one virtual cluster).
Keeping software versions up-to-date is a fundamental aspect of security. You thus probably already realize that it’s critical to keep your Kubernetes release upgraded to the latest stable version.
But keeping up-to-date goes beyond just upgrading Kubernetes itself. Kubernetes continues to evolve, and new releases tend to introduce new security features, or require an overhaul of older ones.
The point here is that it’s not enough just to update Kubernetes whenever a new version comes out. You should also carefully read the release notes for that version and determine whether there are any additional security features you can take advantage of (like new pod security policy variables, for example), or whether there are security-related configurations that you have to update.
It would be nice if Kubernetes secured itself. But it doesn’t and it never will. And even well-designed Kubernetes distributions often lack important security features out of the box. That’s why it’s important to take ownership of your Kubernetes deployments by turning on extra security features, and ensuring that those features remain properly configured as your Kubernetes deployment evolves.