NSA & CISA Kubernetes Hardening Guide – what is new with version 1.2

In August 2022, NSA & CISA has issued a new version of the Kubernetes Hardening Guide – version 1.2. It updates the previous version that was released in August 2021. Kubernetes evolves fast, and Kubernetes adoption grows even quicker. Kubernetes has become a very popular target and therefore requires continuous enhancement of the protection measures.

The approach that NSA & CISA became popular and is used by many because it inspires readers to understand the root cause of each recommendation, why it is essential, and how malicious actors may utilize it. In addition to helping the readers understand what to enable and disable, the document helps map the threat landscape onto your specific solution and understand how potential attacks will influence your system.

The new version of the document shows that its authors follow Kubernetes and cloud security very closely and try to help the industry be ready for the next wave of threats driven by the evolution of the attack methodologies and the new features offered by Kubernetes and cloud platforms.

Several most important points addressed in the new version of the NSA & CISA Kubernetes Hardening Guide are provided here below:

Kubernetes infrastructure hardening

ETCD: ensure encryption at rest; mutual TLS communication between ETCD and KubeAPI server; use separate Certificate Authority for ETCD communication.

Container Runtimes: emphasized the necessity of continuous vulnerability scanning of the container runtime images and Kubernetes resident components as part of the supply chain threat.

Control plane hardening: use TLS and disable anonymous authentication in the control plane communication interfaces.

RBAC: much more focus is placed on the RBAC enablement and configuration. New recommendations include additional role separation. For example, it is recommended to separate between administration and infrastructure management roles.

User authentication

User authentication was treated as out-of-scope in the previous version of the document. The new version focuses on the importance of user authentication and suggests using strong multi-factor authentication methods even though they are not part of Kubernetes itself. The guidelines give clear direction to rely on the third-party products in this area.

Use and continuously monitor RBAC to ensure the least privileged principle among authorized users and user groups.

Disable all unauthenticated interfaces and anonymous authentication. Treat potentially stolen credentials as a viable and dangerous threat and use short-time tokens and third-party tools to mitigate this.  

Deprecation of PSP

For those who used PSP, it is recommended to move to PSA (starting from v1.23). However, this section also recommends considering third-party admission controllers as a more flexible and customizable mechanism.

Admission controller

While admission controller is not a new mechanism and was also present in the previous version of the document, the new version adds more requirements/expectations. In addition to the enhanced PSP/PSA mechanism, admission controllers are now expected to validate container image signatures and perform enhanced configuration validations.

POD Service Account token protection

The earlier version has recommended removing Service Account tokens from all PODs that are not designed to communicate with KubeAPI. This recommendation is still valid. However, some new capabilities from CSPs now enable usage of the SA token to authenticate against platform services that are beyond Kubernetes control. If these capabilities are in use, assigning empty RBAC roles to such Service Accounts is now recommended.

Application container hardening

The document emphasizes the importance of continuous image scanning as new vulnerabilities appear every day; usage of private/closed image repositories; use of sandboxing and seccomp technologies (on top of least privileged principle); usage of network policies and CNI that supports them; special attention is paid to ingress policy necessity; explicit recommendation to always start from default denial policy and then enable necessary routes (which may not always be scalable, but definitely the most secure).

Auditing and Logging

The new version pays more attention to logging node services and applications themselves and suggests using third-party tools that can correlate and analyze all the logs together.

The document explicitly warns about a potential conflict in logging depth and exposure of potentially sensitive information such as Kubernetes secrets.

How Kubescape can help

Kubescape was the first tool offering Kubernetes misconfigurations scanning according to NSA & CISA Guidelines framework right after they were published. Since its launch, Kubescape has added many important security features inspired by NSA & CISA approach to the Kubernetes security assessment. It remains the leading open-source tool offering this and several additional frameworks today.

Some of the new verifications require deep visibility of the node configuration. I want to encourage you to use “–enable-host-scan” flag allowing Kubescape to verify important node configuration aspects such as TLS protected communication with KubeAPI, anonymous authentication deactivation, and many more.

We continue adding to Kubescape continuously new verification controls to adhere to the latest threat landscape and keep up with the evolution of the security frameworks such as NSA & CISA guidelines. Some of the new requirements in this new version were already implemented in Kubescape. Such controls may be present in other frameworks, so they will be added to the NSA framework shortly.

Continuous container vulnerability scanning provided by Kubescape enables a better contextual assessment of your potential risk score. Critical vulnerabilities pose more danger to your system when they are found in the privileged PODs, PODs open to the ingress traffic, or PODs that possess privileged Service Account tokens.

By Security standards, at DevOps pace.

Actionable, contextual, <br/> end-to-end <br/> Kubernetes-native security

See ARMO in Action