KubeLinter is an open source static analysis tool—also referred to as a lint or linter—that identifies misconfigurations and programming errors in Kubernetes deployments. The command-line tool automatically analyzes YAML files and Helm charts against Kubernetes configuration and security best practices.
See KubeLinter in action
Learn how the command-line tool works in this hands-on demonstration.
Kubernetes—also known as K8s—is popular for its ability to deploy, manage, and scale containerized applications but is not known for its ability to secure containers. Kubernetes configurations are also typically defined in YAML files, which are human-readable yet challenging to understand and produce valid configurations at scale. Static validation alone in complex YAML cannot easily catch errors and violations, which can expose security issues.
And security is essential.
According to Red Hat’s Kubernetes adoption, security, and market trends report for 2021, more than half of those surveyed said they delayed deploying Kubernetes applications into production because of security concerns, with 94% experiencing at least 1 Kubernetes-related security incident in 2020. This was primarily due to human error, with manually entered misconfigurations contributing to about 67% of cases reported.
This is where KubeLinter comes in.
The lint tool—created by StackRox in late 2020 shortly before it was acquired by Red Hat in early 2021—is specifically designed to combat security errors and improve accurate configuration across Kubernetes deployments at the beginning of the development process. It carries out config file checks and can be used with continuous integration (CI) systems to simplify the process of updating YAML files and Helm charts while employing DevSecOps best practices.
As an open source tool available under the Apache 2.0 license, KubeLinter also allows users throughout the open source community to contribute to the project.
To verify that Kubernetes clusters are set up correctly and that programming bugs are fixed before deployment, KubeLinter takes a path to a chart and runs a series of tests to verify that the chart is well-formed and error-free. It then sends lint error messages for anything it finds that causes the chart to fail installation or a warning message for anything that doesn't align with Kubernetes security best practices.
KubeLinter also was designed to be easy to run. It comes prepackaged with 40 built-in lint checks for common K8s misconfigurations like running a container as user, mismatching selectors, and storing sensitive data only in secrets. It supports configuration of custom checks and lets users treat configurations as code, allowing them to build security into the application development process much earlier.
KubeLinter is highly configurable. Users can create, enable, and disable their own custom rules with minimal changes to workflows and near-instant feedback on misconfigurations and security violations.
KubeLinter can be added to any continuous integration/continuous delivery (CI/CD) tool—including GitHub Action, Jenkins, CircleCI, and Travis CI—and can automatically check for and identify errors in application configurations. This helps developers with remediation efforts, and they can automatically see problems throughout the production pipeline.
KubeLinter default checks are also centered around security, so users must manually opt in if they want to configure Kubernetes in a insecure way.
KubeLinter takes a few minutes to download and install. Developed as a self-contained binary using the human-readable Go programming language, it is comparable to kubectl and is made with a few of the same packages.
To install KubeLinter, you can build the command-line interface locally using Go, use pre-built Docker containers, install using Homebrew, or build it yourself from source code. After installation, point the tool to your Helm charts and Kubernetes YAML files to get results almost immediately.
Because it’s an open source tool, developers can and should expect changes to elements of KubeLinter as it’s further developed. Changes can include configuration file formats, flags, and command usage.