Monolithic applications are outdated. We are now solidly in a development revolution as rapid software development and deployment have become standard. Microservices and containers are key to enabling this new way of working driven by DevOps practices such as Continuous Integration and Continuous Delivery. As a result, securing Kubernetes master and worker nodes has become critical.
Harnessing the Value of Microservices and Kubernetes
As we welcome 2020, we expect mass migration to microservices. By enabling you to structure an application into several modular services, microservices bring:
- Improvements to scale
- The ability to withstand high server loads
- Faster deployments
- Easy fault isolation
Microservices offer flexibility in using a wide mix of technologies and having autonomous, cross-functional teams. But as microservices grow in popularity, so does the attack surface, so they require a different approach to security.
Kubernetes is one of the fastest-growing container orchestration platforms used to implement microservices and has more than a 50% market share. The idea behind the tool is to operate with containers, which contain a microservice—a small part of your application. Kubernetes by itself is secured, but no one can be safe from server misconfiguration, which was identified as one of the biggest threats in public cloud for security leaders in 2018.
For example, in 2018 hackers got access to Tesla`s Kubernetes and ran cryptocurrency miners on their cluster. So how do you secure the Kubernetes cluster?
CloudPassage Policy Templates Support Securing Kubernetes
Support for securing Kubernetes was released in CloudPassage Server Secure enabling customers to evaluate the security posture of their Kubernetes infrastructure.
Users can now perform security assessment scans of Kubernetes Master nodes and Worker nodes using our two Kubernetes policy templates, which are based on the CIS Benchmark standard. The master node policy template has 73 security configuration assessment rules, e.g. Ensure that the — anonymous-auth argument is set to false; while the worker node policy template has 23 security configuration assessment rules, e.g. Ensure that the –event qps argument is set to 0.
Kubernetes Security Scan Results
Let’s take a closer look at how our Kubernetes security support works. The scan results below are the output of a scan on a freshly installed default Kubernetes master node installation.
As you can see, a default Kubernetes installation needs a lot of work to be completely secure. Many benchmark rules produce ‘fail’ results which implies that the configuration needs hardening.
Users can select any individual rule and go over the ‘Description’ and ‘Rationale’ fields to understand the check. If required, users can perform manual tests using the steps from the ‘Audit’ section. And finally, follow the guidance from the ‘Remediation’ section to secure their configuration. An example of one such rule is shown below:
Rule Details for: Ensure that the — anonymous-auth argument is set to false
Similar results are seen with the scan of the worker node. The CSM scan produces many fail results as seen below which implies that these settings need to be hardened to secure the configuration.
Configuration Checks of Note
Some of my favorite configuration checks for securing Kubernetes in this policy template are listed below with links to find more information:
- All checks with certificates are immensely important as Kubernetes components interact with each other via API calls. For more information: https://kubernetes.io/docs/concepts/
- 1.1.24 PodSecurityPolicy because PodSecurityPolicy defines what and how to run in the cluster. For more information: https://kubernetes.io/docs/concepts/policy/pod-security-policy/
- 1.1.39 “Ensure that the –authorization-mode argument includes RBAC”, because RBAC is a powerful method to restrict permissions in the cluster. For more information: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Securing Container Runtimes
In addition, Kubernetes can be configured to use different container runtimes, with Docker being a popular choice in most cases. This implies that users should harden Docker as well as securing Kubernetes, which can be done using the CloudPassage Docker template that evaluates the security posture of a Docker configuration. Users should also keep in mind that all of these applications are running on the operating system which itself has many attack vectors.
- Users managing Kubernetes’ master and worker by themselves should use CloudPassage OS policy templates for a security evaluation.
- If users are using a public cloud (like AWS or Azure) to run their workers they should use CloudPassage Cloud Secure to evaluate the security posture of their cloud infrastructure.
To conclude, Kubernetes and microservices are great infrastructure choices. Although when it comes to securing Kubernetes, users should assess not only Kubernetes but container runtimes as well as operating systems or cloud infrastructures to get a complete end-to-end view of their security posture.
Learn how the CloudPassage Halo cloud security platform for servers can help secure the servers in your Kubernetes infrastructure.
Learn more about how the CloudPassage Halo platform helps with container security.
Get a free vulnerability assessment of your infrastructure in 30 minutes.