NSA’s Kubernetes Hardening Guidelines and Pod Security
I previously asked (and answered) the question, What Are the NSA K8s Guidelines and Why Should You Care? I suggested that the first step to compliance is to understand your Kubernetes environment. The next step is to review the five categories and start somewhere!
You’ll need to decide which of the five areas—pod security, network separation and hardening, authentication and authorization, audit logging and threat detection and upgrading and application security practices—will have the biggest security impact for your business. When in doubt, pod security is a solid place to start.
Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. It makes sense that ensuring pod security will help harden your Kubernetes environment. There are four main areas to consider with pod security:
- Use containers built to run applications as non-root users
The NSA recommends running applications as non-root users. The guidelines say, “By default, many container services run as the privileged root user, and applications execute inside the container as root despite not requiring privileged execution. Preventing root execution by using non-root containers or a rootless container engine limits the impact of a container compromise.” Unfortunately, it’s often easier to over-permission a Kubernetes deployment with root access to just get something working, but it’s not recommended. As more pods are created, you may unknowingly be running many pods as root. - Run containers with immutable file systems
As part of your security, you do not want cyberattackers to be able to write to local file systems. To achieve this, you must check for writable file systems. The guidelines say, “By default, containers are permitted mostly unrestricted execution within their own context. A cyber actor who has gained execution in a container can create files, download scripts and modify the application within the container. Kubernetes can lock down a container’s file system, thereby preventing many post-exploitation activities.” - Scan container images for possible vulnerabilities
We know that container vulnerabilities can open an organization up to attacks. The NSA says that “image scanning is key to ensuring deployed containers are secure.” Just recently, we saw the zero-day vulnerability known as Log4j announced. Log4j was simple to take advantage of and embedded in a vast array of applications, services and software tools—the vulnerability could easily be employed by bad actors. Consistently scanning containers for vulnerabilities—both new and old—is just good practice. - Use a technical control to enforce a minimum level of security
The NSA specifically recommends the following:
- Preventing privileged containers
- Denying container features frequently exploited to break out, such as hostPID, hostIPC, hostNetwork, allowedHostPath
- Rejecting containers that execute as the root user or allow elevation to root
- Hardening applications against exploitation using security services
These are common security issues that teams should check against. While the NSA does suggest hardening applications, there are open source tools like Open Policy Agent (OPA) that can help with customized policies to harden applications.
Complying with the NSA
Now that you have an overview of what needs to be done, how can DevSecOps teams meet the NSA hardening guidelines? DevSecOps teams need a way to precisely see which workloads have permissions to run as root or if containers can write to file systems. They also need to continuously scan against known vulnerabilities.
Open source tools like Polaris can help identify those workloads that do not comply with the Kubernetes best practices that align with the NSA hardening guidelines. Trivy, another open source tool, can help scan for known vulnerabilities. With these tools in place, you can see where your pod security might be failing and fix it.
Preventing Production Issues
Beyond that, teams need a way to lock down the ability to deploy containers with known issues like root access, write privileges or a present vulnerability. Admission controllers, when used with tools like Polaris, can help teams prevent any containers from reaching production with these known issues.
NSA Guidelines at Scale
Open source tools can help teams scratch the surface of NSA hardening compliance. If DevSecOps teams are running Kubernetes and containers at scale, it’s only a matter of time before the open source tools fail to keep up. That’s where Kubernetes governance and guardrails software can come into play. DevSecOps leaders can set policy or guardrails to continuously scan against NSA requirements, alert teams when there is an issue and advise on a fix. Better yet, governance can help prevent any issues from reaching production.