Kubernetes manifests are a critical part of your Kubernetes deployment, and ensuring they’re linted correctly is important for both performance and security. In this article, we’ll show you how to lint your Kubernetes manifests with Kube-Score. ..
Kube-Score is a Kubernetes static analysis tool which lints your resources to identify security and reliability issues. Running Kube-Score before you apply manifests to your cluster can help you identify pain points before they turn into real problems.
Getting Started
Kube-Score’s offered in several installation formats. Pre-built binaries are available for Windows, macOS, and Linux from GitHub. Alternatively, you can use the Brew package manager on macOS (brew install kube-score/tap/kube-score), or add Kube-Score as a kubectl plugin (kubectl krew install score).
Run Kube-Score using the kube-score command in your terminal. It accepts the path to a Kubernetes YAML manifest file. Wildcards are supported to scan multiple matching files and entire directories.
Kube-Score also works with manifests piped in from standard input. This lets you run the tool against a live Kubernetes cluster. Use kubectl to access a resource’s manifest and pipe it into the command. Here’s the recommended way of analyzing your entire cluster:
This mechanism also facilitates use with Helm charts. Use the helm template command to render your chart as a regular Kubernetes manifest. Pipe this output into kube-score:
Colorized test results are emitted directly to your terminal. Each failed check includes a description of the test and suggestions for possible resolutions. Review the output to identify ways of improving your manifests.
Tests will be marked as either WARNING or CRITICAL. A critical fail usually requires immediate remediation. Warnings may not need to be resolved, depending on your specific situation.
Human-readable output can be disabled with the –output-format flag. Set this to json or ci to get machine-readable content that’s easily parsed by other tools. The ci format is intended to aid consumption by CI/CD systems, whereas json gives you a JSON representation of the regular console output. Kube-Score always exits with a status code of 1 when errors are detected.
If you want to experiment with Kube-Score, you can use the live analyzer on the project’s website. This lets you write a manifest and observe its scan results in real-time. It’s handy when you’re quickly experimenting with Kube-Score or your manifests.
What Does Kube-Score Check?
Kube-Score runs over 20 different checks covering a broad range of security and reliability concerns. These include tests for proper container resource limits, correct use of ingress and egress routes, and configuration of container readiness probes for health checks.
Here are some of the built-in rules:
Prohibit use of the latest tag for images. Ensure each Pod has an image pull policy of Always, so that pull secrets are validated on each attempt. Check Pods have valid probe configurations and network policies. Check all labels on all resources are valid. Check for prohibitive Pod anti-affinities which would prevent other Pods from being scheduled to the same worker node. Check all Services target a valid Pod. Ensure containers use a read-only root filesystem, without privileged mode.
You should refer to the Kube-Score README for an exhaustive list of available checks. In many cases, the default set will be sufficient to give you visibility into the most common manifest problems.
Optional Rules
Some rules are optional and off by default. These are generally subjective cases which could cause unexpected failures if enforced globally.
Optional tests are enabled by passing the –enable-optional-test flag to the kube-score command. It takes a test ID to add to the scan. Multiple optional tests are activated by repeating the flag.
This command runs Kube-Score with an extra test for explicit user and group IDs. The check fails if a Pod runs without manually set user/group IDs of 1,000 or greater.
You can disable tests in a similar way with the –ignore-test flag. This takes a test ID to remove from the scan. In addition, the –ignore-container-cpu-limit and –ignore-container-memory-limit flags inhibit Kube-Score’s usual insistence that every container possesses manually configured CPU and memory limits.
Managing Kubernetes Versions
Kube-Score currently assumes you’re using Kubernetes v1.18. If you’re running a different version, specify it with the –kubernetes-version flag. This informs Kube-Score which checks are actually relevant to your deployment environment. Not specifying the correct version could result in false positives or negatives, giving you an inaccurate picture of your cluster’s resilience.
Kube-Score expects your individual resources to use stable Kubernetes APIs. Any resources referencing beta APIs that have been superseded by a stable version will fail the test.
Summary
Kube-Score provides simple static analysis for Kubernetes resource manifests. It lets you learn about potential issues before you try to deploy to your cluster. Running Kube-Score as part of your CI pipeline gives you confidence that your resources are correctly configured and your cluster will operate reliably.
For best results, feed Kube-Score all of your resources. It’s most effective when its input includes every resource in the same namespace. Otherwise, you might find some issues are overlooked if they appear due to a conflict with another manifest.
Remember that Kube-Score isn’t an exhaustive analysis of your cluster. It’s an assistive tool, not a complete checklist that guarantees a watertight cluster. You should still independently audit your environment to maintain strong security and peak performance. Kube-Score’s best used as a day-to-day utility that increases the safety of individual deployments.
