A background

In Kubernetes, we use yamL syntax to describe business resources for IaC, either using a separate resource manifest file or using Helm’s charts. Does yamL syntax have the same syntax checks as in other languages as lint? Is there a way to detect kubernetes misconfiguration in advance at the writing stage, and is there a tool to check that the code follows Kubernetes best practices?

At the same time, in the DevOPS era, syntax error detection is not limited to code business itself in GitOPS workflow, but also needs to test configuration code, a YAML detection tool becomes particularly important.

Two kubelinter profile

KubeLinter is an open source yamL detection tool designed to help users detect misconfigurations of Kubernetes. It allows developers to easily detect misconfigurations of Kubernetes before the Kubernetes YAML files and HELM diagrams are deployed to the cluster. Best practices are checked and analyzed and debugged.

Once you feed the YAML file to the tool, it runs through built-in checks and then reports any errors and remedies to resolve them in detail. The best thing about this tool is that it is configurable and extensible: built-in checks can be enabled or disabled, and you can define and use your own custom checks.

3 Installation and Deployment

3.1 MacOS installation

brew install kube-linter
Copy the code

The 3.2 Linux installation

With binary installation, you can find the version you want to install in Release.

Wget tar ZXVF - https://github.com/stackrox/kube-linter/releases/download/0.1.3/kube-linter-linux.tar.gz kube-linter-linux.tar.gz mv kube-linter /usr/bin/Copy the code

4 use

4.1 YAML to be detected

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false
Copy the code

4.2 Performing Detection

kube-linter lint pod.yaml
Copy the code

4.3 Viewing test results

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in your container's securityContext.)

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set    your container's CPU requests and limits depending on its requirements. See    https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/   #requests-and-limits for more details.)

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has memory limit 0 (check: unset-memory-requirements, remediation:    Set your container's memory requests and limits depending on its requirements.    See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/   #requests-and-limits for more details.)

Error: found 3 lint errors
Copy the code

As you can see, errors are found in YAML files, and each error has a specific remedial step.

4.4 Checking the Detection Type

If you want to have a look at the built-in checks, all these checks can be listed on https://github.com/stackrox/kube-linter/blob/main/docs/genic/checks.md, or you can also use KubeLinter check list:

4.5 Ignoring Detection

You can ignore specific checks for YAML files using the following comments, or you can ignore check groups as needed:

ignore-check.kube-linter.io/<check-name>
#Such as:
ignore-check.kube-linter.io/unset-cpu-requirements

Copy the code

You can add the ignore check rule to the above deployment file example as above:

metadata: name: portainer namespace: portainer labels: io.portainer.kubernetes.application.stack: portainer app.kubernetes.io/name: portainer app.kubernetes.io/instance: portainer app.kubernetes.io/version: Annotations: "2.0.0" Annotations: ignore-check.kube-linter. IO /unset-cpu-requirements: "CPU requirements not required"Copy the code

Now, when you run kube-Linter Lint deploy.yaml again, you should not see errors related to CPU requirements.

4.6 Using Configuration Ignore

KubeLinter can also be run using a configuration where you can provide all the detection information to include/exclude. Here is a sample configuration in the repository:

# customChecks defines custom checks.
customChecks:
- name: "required-label-app"
  template: "required-label"
  params:
    key: "app"
checks:
  # if doNotAutoAddDefaults is true, default checks are not automatically added.
  doNotAutoAddDefaults: false

  # addAllBuiltIn, if set, adds all built-in checks. This allows users to
  # explicitly opt-out of checks that are not relevant using Exclude.
  # Takes precedence over doNotAutoAddDefaults, if both are set.
  addAllBuiltIn: false

  # include explicitly adds checks, by name. You can reference any of the built-in checks.
  # Note that customChecks defined above are included automatically.
  include:
  - "required-label-owner"
  # exclude explicitly excludes checks, by name. exclude has the highest priority: if a check is
  # in exclude, then it is not considered, even if it is in include as well.
  exclude:
    - "privileged"
Copy the code

Yaml if you run kubelinter –config config Lint deploy.yaml, where config is attached to the above configuration file, you should see checks that add the required labels:

deploy.yaml: (object: portainer/portainer apps/v1, Kind=Deployment) no label matching "owner=<any>" found (check: required-label-owner, remediation: Add an email annotation to your object with information about the object's owner.)
Copy the code

KubeLinter can prove to be a very useful tool when built into CI pipes. Orchestration files pushed to the repository can be checked and validated for best practices and security considerations, and alerts can be generated when problems are detected.

Five integrated into DevOPS

Integrating Kubelinter into CI is a good place to check Kubernetes before deploying real applications to the environment.

In this way, applications deployed to the cluster can undergo a healthy readiness check. The project is in Alpha, but is expected to serve as a CI integration tool to validate all deployments prior to actual deployment to production.

Six reflection

Daily check for business Kubernetes resource manifest files can be done using –dry-run. Check for Kubernetes best practices can be done using Kube-Linter. Install it locally in an open environment or integrate it into DevOPS. Are able to discover and optimize resource manifest files in a timely manner.

Refer to the link

• Mp.weixin.qq.com/s/Qo2SgTCvV…
• Github.com/stackrox/ku…
• Github.com/stackrox/ku…