Earlier this month, the NSA released a number of recommendations for hardening Kubernetes clusters. The guide outlines a really strong defense-in-depth approach to ensure that when an attacker compromises your cluster, the blast radius will be as small as possible. The NSA Kubernetes hardening guide includes the following recommendations:
Kubernetes is not secure out-of-the-box. By default, everything you deploy to your cluster is able to communicate with everything else. Pods can run as root, and even if you disable privileged mode, there are still plenty of pod settings that an attacker inside your cluster can enable to get root access to the underlying node.
Unfortunately, there is a pretty standard process for attacking that cluster you’ve spent so much time working on. Consider the many possible attack vectors: using a leaked kubeconfig or leaked cloud credentials, a supply side attack, an exposed dashboard, or exploiting a known security vulnerability. The attacker can then execute some of their own code within your cluster, escalate privileges, and then cover their tracks. All of this behavior happens while also creating a persistent foothold, enabling attackers to steal secrets and data, consume compute resources for financial gain, or achieve any number of other results.
Securing your microservices against attacks is getting harder and harder as architecture continues to grow increasingly complex. Do you know if every pod in your Kubernetes cluster has hostPath disabled? How about the flow of network traffic through your cluster — are pods able to communicate with control plane components or neighboring namespaces? These little details are the difference between an attack’s blast radius being limited to a malicious container from a supply side attack to having your cluster compromised, or even having your cloud account compromised. This could happen if an attacker escaped the pod, used the node’s cloud credentials to gain access to your account, and found more ways to escalate privileges.
From an insider threat perspective, role-based access control (RBAC) is essential for ensuring that only appropriate individuals in your organization have access to the Kubernetes cluster. Managing RBAC profiles, and even gaining visibility into what's configured, can be an overwhelming task. A malicious insider acting inside the cluster could use existing permissions or elevate their permissions by exploiting known vulnerabilities, which is why it's critical to manage RBAC permissions, monitor for and patch known vulnerabilities in containers, and review the security permissions of your services.
Using open source software, such as Fairwinds’ Polaris, is a great first step towards checking your service configuration. With Polaris, you'll get a point-in-time snapshot of your Kubernetes security posture. Polaris also provides other best practice recommendations to help you discover Kubernetes misconfigurations and avoid problems.
While Polaris improves Kubernetes deployments, the NSA Hardening Guide advocates for a more continuous approach to Kubernetes security. Fortunately, several of these recommendations can be implemented using Fairwinds Insights, which combines Polaris with other open source tools to provide a platform that simplifies Kubernetes complexity and reduces risk.
With Fairwinds Insights, you'll be able to operationalize Polaris to run on a continuous basis and integrate multiple open source security tools from CI/CD all the way through to Production. Fairwinds Insights adds:
If you're interested in learning more, please book a demo of Fairwinds Insights to learn how it can help you harden your Kubernetes environments.
