[FEATURE_REQUEST]: Handle test hooks

[mmorel-35]

Description of the problem/feature request

There shall be different expectations for test resources.

Description of the existing behavior vs. expected behavior

When a Helm Chart provides resources with "helm.sh/hook": test they are linted as standard resources

Additional context

• https://helm.sh/docs/topics/chart_tests/

[janisz]

So basically we should ignore (or add option to ignore) objects with test annotation:

  annotations:
    "helm.sh/hook": test

On the other hand we can skip the whole directory templates/tests with config --ignore-paths "**/templates/tests/*"

$ helm create demo
$ helm package demo
$ ./kube-linter lint demo-0.1.0.tgz
KubeLinter development

./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in the container securityContext.)
./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" is not set to runAsNonRoot (check: run-as-non-root, remediation: Set runAsUser to a non-zero number and runAsNonRoot to true in your pod or container securityContext. Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ for details.)
./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" has cpu request 0 (check: unset-cpu-requirements, remediation: Set CPU requests for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)
./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)
./demo-0.1.0.tgz/demo/templates/tests/test-connection.yaml: (object: <no namespace>/test-release-demo-test-connection /v1, Kind=Pod) The container "wget" is using an invalid container image, "busybox". Please use images that are not blocked by the `BlockList` criteria : [".*:(latest)$" "^[^:]*$" "(.*/[^:]+)$"] (check: latest-tag, remediation: Use a container image with a specific tag other than latest.)
./demo-0.1.0.tgz/demo/templates/tests/test-connection.yaml: (object: <no namespace>/test-release-demo-test-connection /v1, Kind=Pod) container "wget" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in the container securityContext.)
./demo-0.1.0.tgz/demo/templates/tests/test-connection.yaml: (object: <no namespace>/test-release-demo-test-connection /v1, Kind=Pod) container "wget" is not set to runAsNonRoot (check: run-as-non-root, remediation: Set runAsUser to a non-zero number and runAsNonRoot to true in your pod or container securityContext. Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ for details.)
./demo-0.1.0.tgz/demo/templates/tests/test-connection.yaml: (object: <no namespace>/test-release-demo-test-connection /v1, Kind=Pod) container "wget" has cpu request 0 (check: unset-cpu-requirements, remediation: Set CPU requests for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)
./demo-0.1.0.tgz/demo/templates/tests/test-connection.yaml: (object: <no namespace>/test-release-demo-test-connection /v1, Kind=Pod) container "wget" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)


$ ./kube-linter lint demo-0.1.0.tgz --ignore-paths "**/templates/tests/*"
KubeLinter development

./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in the container securityContext.)
./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" is not set to runAsNonRoot (check: run-as-non-root, remediation: Set runAsUser to a non-zero number and runAsNonRoot to true in your pod or container securityContext. Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ for details.)
./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" has cpu request 0 (check: unset-cpu-requirements, remediation: Set CPU requests for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)
./demo-0.1.0.tgz/demo/templates/deployment.yaml: (object: <no namespace>/test-release-demo apps/v1, Kind=Deployment) container "demo" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

What do you think? Maybe we should document this better

[mmorel-35]

The path detection is a good start. Having a complete exclusion seems to strong. For example you will want to forbid root user on a test pod (run-as-non-root) but having three replicas will be to much (minimum-three-replicas)

[janisz]

OK, got it. I think we have 2 options.

1. Add exclude paths to all templates and allow filtering on template level. Something similar to supported object kinds but working on paths and excluding files.

kube-linter/pkg/run/run.go

Line 57 in ce7e193

if !check.Matcher.Matches(obj.K8sObject.GetObjectKind().GroupVersionKind()) {

2. We can follow approach of golangci-lint where they have a separate rules filter. But I think that's because not all linters are in their control and we control all our templates.