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.

CONSIDER THIS A PROTOTYPE. PLEASE PROVIDE FEEDBACK IN THE ISSUES

Only Pod linting is currently implemented

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

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

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

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
tags:
- 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.

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.

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

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

• 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.