The National Security Agency (NSA) released its Kubernetes Hardening Guide in August 2021 (and updated it in March 2022) with 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. This is essential for cybersecurity and infrastructure security in Kubernetes.
The NSA Kubernetes Hardening Guide includes the following recommendations:
Kubernetes, and many cloud native technologies, are 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 which is why the NSA has provided guidance. 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 have misconfigurations? 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 or authentication 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 (or misconfigured), 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. All of this is essential to ensuring cloud native security.
Using open source software, such as Fairwinds’ Polaris, is a great first step towards checking your service configuration. Polaris is an open source technology with out-of-the-box Kubernetes security best practice checks.
The NSA guide suggests users do not run containers as root. 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. This includes checking to ensure that containers do not run as root.
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.
By adopting Polaris via Fairwinds Insights, you can see precisely which workloads currently in your clusters have permission to run as root. Furthermore, you can use Insights to run the same policy in your CI/CD pipeline, ensuring that infrastructure-as-code changes don’t introduce new resources with the ability to run as root.
Once you’ve locked down the ability to run as root across all applicable workloads, we recommend turning on Polaris in the Insights Admission Controller, which provides the strongest defense against workloads that run as root.
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:
Based on the March 2022 updates, Fairwinds has provided a step by step guide on how to meet the NSA Kubernetes Hardening Guidelines. The Guide provides recommendations using open source and cloud native technologies as well as Fairwinds Insights and Polaris.
