Miracle of KubeLinter

Hi everyone, I’m Elman. Today, I will tell you about the miracle of KubeLinter, as the title suggests. Let’s forget about the Helm problems we used to have. “I wonder where did I go wrong?”, “Okay, I prepared the Helm docs, but are there any other extensions I need to install?”, “I wonder if the annotations I have installed are correct? or Do I leave a secure hole?” KubeLinter will now answer our questions for us. Let’s start over 😊

What is KubeLinter?

KubeLinter is a tool that analyzes Kubernetes YAML files and Helm charts and warns us against dangers and vulnerabilities that may occur during deployment.

KubeLinter is designed to give you useful information about your Kubernetes YAML files and Helm charts, and warns you of potential dangers by working through sensible default states at check time. This tool exists to help Cloud teams frequently check helms of DevOps best practices for security misconfigurations.

KubeLinter is configurable. So you can enable and disable controls as well as create your own custom controls depending on the policies you want to follow in the helm build or K8S yaml files. Of course, you can do this by giving commands from outside or passing annotation inside the yaml file. Don’t worry, I’ll talk about that too. Let’s continue 😉

KubeLinter Installation

1 git clone git@github.com:stackrox/kube-linter.git

2cd kube-linter && make build

3cp .gobin/kube-linter /bin/kube-linter (/usr/bin) && kube-linter version

If we did not encounter any problems during the installation and we were able to see the version output, it means that the installation process has been completed successfully. The next step will be usage and output. Here we will talk about how to apply the processes and the results.

KubeLinter Usage and Outputs

kube-linter lint /path/to/your/yaml.yaml

Let’s try this command with an example yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Now let’s see which secure vulnerabilities and wrong structures exist in our helm structure using the kube-linter command.

kube-linter lint /opt/example.yaml

Now let’s check our output and see what is problems about KubeLinter warns.

1. check: no-anti-affinity Policy: As we know, pods handle a certain nodeAffinity information and distribute it over the relevant nodes. If we do not pass this information on yaml, then Kubernetes does this for us by default, and whichever nodegroup is available, the pod starts working on that node and the traffic starts to flow through that node. This is the structure we cannot manage. That’s why KubeLinter warns us about this.
2. no-read-only-root-fs Policy: Here, KubeLinter provides control over yaml using the relevant policy and shows us that the nginx structure has root privileges on the file system and this operation is dangerous. Here it recommends having read-only privilege. run-as-non-root Policy also warns us that some processes should not have root privileges and it states that this process is Secure.
3. unset-cpu-requirements, unset-memory-requirements Policy: Here KubeLinter warns us that Cpu and Memory limits as well as request information should be given on yaml. Because if we do not make this limitation, then it will use unlimited CPU and memory as Defult on the pod node. This, of course, is a situation we do not want to encounter.

Above we reviewed some of KubeLinter’s Policies. So what should we do if we want a more detailed control that ensures the use of all policies? All policies will be active here. KubeLinter is thinking of us in this regard as well, and an additional command comes to our support.

kube-linter lint path/to/example.yaml — add-all-built-in

This command shows us in more detail what problems are in the helm file and with deafult problems that may occur in the yaml file. In other words, when we use this command, while there are normally 7 faulty transactions, it increases up to 16 faulty transactions. The aim is to help us prepare the most suitable yaml for best practices by showing more errors (with default problems).

If we want to disable all control policies, we can use this command for that. KubeLinter thinks about users in every way.

kube-linter lint path/to/example.yaml — do-not-auto-add-defaults

By using this flag, we will disable the defult warning check. We will no longer see the default warnings in the helm yaml files and in this way we will have disabled all the controls. But of course the recommendation is not to use it.

So, let’s say we want some Policy not to be used on the helm structure, what should we do? Don’t worry, KubeLinter is thinking of us again in this regard. If we pass these policies as annotation on the helm structure, when the Policy gets here, it skips here and prints the information we provide to the screen.

Example:

- annotations:
    ignore-check.kube-linter.io/unset-cpu-requirements : “No cpu tuning required.”

The policy information we will add to Annotation is as follows:

1. env-var-secret
2. no-liveness-probe
3. no-read-only-root-fs
4. no-readiness-probe
5. non-existent-service-account
6. required-annotation-email
7. required-label-owner
8. run-as-non-root
9. unset-cpu-requirements
10. unset-memory-requirements

ignore-check.kube-linter.io/<check name> : “INFO”

Reference

KubeLinter: https://docs.kubelinter.io/#/

Today I tried to explain the KubeLinter tool step by step for you. I hope it was an article that you will enjoy reading and enjoying. Happy reading already… 😊

To read the Turkish version of the article, please click on the link below:

https://thebadalov.medium.com/kubelinter-mucizesi-6bfec4934cdc