A linter for Kubernetes resources with a customizable rule set
Clone or download
Vic Iglesias Vic Iglesias
Vic Iglesias and Vic Iglesias Fix travis steps for unix paths
Latest commit 748bc23 Mar 12, 2017
Type Name Latest commit message Commit time
Failed to load latest commit information.
cmd Fix error with linting local files. Jan 27, 2017
example Handle floats Jan 19, 2017
pkg Fix tests Jan 23, 2017
.gitignore Remove vendor (#5) Mar 11, 2017
.travis.yml Fix travis steps for unix paths Mar 12, 2017
LICENSE Initial Commit Jan 12, 2017
README.md Add filtering to README Jan 20, 2017
glide.lock Update deps to work on windows Mar 12, 2017
glide.yaml Update deps to work on windows Mar 12, 2017
main.go Initial Commit Jan 12, 2017



A linter for Kubernetes resources with a customizable rule set.


kube-lint hopes to make it easy to validate that your Kubernetes configuration files and your running resources adhere to a standard that you define. You define a list of rules that you would like to validate against your resources and kube-lint will evaluate those rules against them.

In many organizations you will want to have a standard for what is considered "correct" enough to be deployed into your Kubernetes clusters. You may have conventions for labels or restrictions on certain types of services being created. You can use kube-lint during your CI/CD pipeline to gate resources being created that do not adhere to your standards. Additionally you can use kube-lint to audit against a running set of resources in your cluster.


Only Pod linting is currently implemented


  • Download a release from the releases page that matches your platform.
  • Extract the archive

For MacOS

wget https://github.com/viglesiasce/kube-lint/releases/download/v0.0.1-prototype/kube-lint-prototype-darwin.tgz
tar zxfv kube-lint-prototype-darwin.tgz
./darwin/kube-lint -h

For Linux

wget https://github.com/viglesiasce/kube-lint/releases/download/v0.0.1-prototype/kube-lint-prototype-linux.tgz
tar zxfv kube-lint-prototype-linux.tgz
./linux/kube-lint -h

Rule configuration

The rule configuration file is a YAML formatted list of KubernetesRules. An example config file is available at example/config.yaml in this repository.

A KubernetesRule has the following format:

name: app-label
description: Includes a label with key "app"
kind: Pod
field: .metadata.labels.app
operator: set
valueType: string
- operations
- security

name is an identifier for this rule.

description provides details about what the rule is checking for.

kind is the type of resource this check should be done against.

field is a jsonpath used to get the value you want to evaluate against.

operator is the check that youd like to do against your expected vs actual values (ie equal, matches, lessthan). For string type the available operators are equal, notequal, set, unset, matches. For bool type the available operators are equal, notequal, set, unset. For float64 type, the available operators are equal, notequal, set, unset, greaterthan, lessthan.

valueType is the type of the value that needs to be evaluated. string is the default. bool and float64 are also implemented.

tags is a list of strings that can be used to decide whether to run this rule or not via the CLI.

Running kube-lint

Basic operation

Once installed you can run kube-lint from this directory as follows:

kube-lint pods --config example/config.yaml

To change the rules edit example/config.yaml. You rulebender you.

Filtering rules by tag

You can evaluate a subset of rules by filtering down to only those that include certain tags. For example:

kube-lint pods --config example/config.yaml --tags security,operations

Filtering resources by namespace

You can also filter which resources are evaluated by passing the --namespace flag as follows:

kube-lint pods --config example/config.yaml --namespace kube-system

TODO if this seems like a reasonable approach to pursue

  • Replace panic everywhere with proper error handling
  • Add tests. Lots of tests.
  • Add docstrings to all exported functions/types/methods
  • Make -f be able to load a directories of yaml files (like kubectl)
  • Decide on how to deal with unset parameters
  • Choose a logging framework and use it
  • Add more resources (services/deployments/etc.)
  • Use ${HOME}/.kube-lint for config params
  • Develop standardized baseline of rules that are useful
  • Vendor dependencies using glide


Add an issue to talk about what youd like to see changed. Lets talk about it then come up with a plan of action.