Kubernetes security is a moving target, and NSA’s hardening guide for Kubernetes provides a set of best practices to secure your cluster. Trivy, a popular security scanner, can help you audit your cluster against this benchmark.
Let’s see Trivy in action, scanning a Kubernetes cluster for NSA hardening compliance.
trivy k8s --report summary --severity HIGH,CRITICAL --config-policy ns-cis-k8s-v1.23.yaml --namespace kube-system .
This command initiates a scan of the kube-system namespace, focusing on high and critical severity findings, using a specific policy file (ns-cis-k8s-v1.23.yaml) derived from the CIS Kubernetes Benchmark, which the NSA guide heavily references. The --report summary flag provides a concise overview of the findings.
The core problem Trivy addresses here is the inherent complexity of Kubernetes security. Misconfigurations are rampant, and manual auditing against a comprehensive standard like the NSA’s hardening guide is time-consuming and error-prone. Trivy automates this process, providing actionable insights into where your cluster deviates from best practices.
Internally, Trivy works by inspecting various components of your Kubernetes cluster. For configuration checks, it interacts with the Kubernetes API server to gather information about cluster resources like Pods, Deployments, Services, and more. It then applies a set of predefined rules (the ns-cis-k8s-v1.23.yaml policy in our example) to these resources. Each rule corresponds to a specific security recommendation from the NSA/CIS benchmark. For instance, a rule might check if hostPath volumes are disallowed for certain workloads, or if pods are running with elevated privileges. When a resource’s configuration violates a rule, Trivy flags it as a finding, indicating the severity and providing details for remediation.
The ns-cis-k8s-v1.23.yaml file is a crucial piece of this puzzle. It’s a declarative representation of the security checks. A snippet might look like this:
apiVersion: v1
kind: Policy
metadata:
name: cis-k8s-v1.23
rules:
- name: "1.1.1 Ensure that the API server pod has the --anonymous-auth=false argument set"
resource: pod
match:
container:
name: kube-apiserver
policy:
required:
args:
anonymous-auth: false
This rule explicitly states that the kube-apiserver container within the API server pod must have the --anonymous-auth=false argument set. Trivy queries the API server for the running kube-apiserver pod, inspects its command-line arguments, and compares it against this requirement. If anonymous-auth is not false or is absent, it’s flagged.
When you run the trivy k8s command, it doesn’t just scan static configuration files. It queries the live state of your cluster. This means it checks the actual running pods, their configurations, and the settings of various Kubernetes controllers. The power lies in its ability to translate complex security recommendations into concrete checks against your deployed resources. You can also scan specific namespaces, or the entire cluster, and filter by severity levels like LOW, MEDIUM, HIGH, and CRITICAL.
The levers you control are primarily the trivy k8s command-line flags and the content of your policy files. You can define custom policies tailored to your organization’s specific security posture, or use established benchmarks like CIS. The --namespace flag allows you to scope your audits, and the --severity flag helps prioritize remediation efforts. For more granular control, you can specify individual checks or groups of checks within your policy files.
The most surprising thing about this process is how often seemingly minor configuration settings can have significant security implications, and how Trivy’s ability to automate these checks reveals them. For example, a common finding might be that certain pods are allowed to run as root or with elevated securityContext capabilities, which can be a stepping stone for attackers to gain deeper access to your nodes. Trivy will pinpoint these specific pods and their offending configurations, often down to the exact line in the deployment manifest or the specific API object.
After you’ve addressed all the high and critical findings from your Trivy scan, the next error you’ll likely encounter is a warning about outdated container images, prompting you to integrate Trivy’s image scanning capabilities into your CI/CD pipeline.