KubeLinter is a static analysis tool that checks Kubernetes YAML files and Helm charts to ensure the applications represented in them adhere to best practices.
Description of the problem/feature requestkube-linter assumes that objects that don't have a namespace specified aren't in any namespace. However, omitting the namespace from a namespaced object's metadata is not uncommon: in this case, the namespace is filled in to be the "current" namespace, as specified via the -n/--namespace flag in kubectl, helm etc., or per the current context from the kubeconfig.
kube-linter should at a minimum support specifying the "current" namespace via an -n flag.
Description of the existing behavior vs. expected behavior
Consider this YAML manifest consisting of a deployment, with an explicit namespace of "default", and a service with no namespace. In a standard kube environment, running kubectl create -f on this file will expose the deployment via the service. However, when running kube-linter lint <file> --do-not-auto-add-defaults --include dangling-service, the dangling-service check will trigger because kube-linter attributes the service to <no namespace>.
While it is accurate that it cannot be assumed for sure that both objects are in the same namespace, it should be possible to convince kube-linter that they are even without modifying the YAML file. For Helm charts, it's standard practice to omit the namespace object from the template in favor of helms -n parameter (see here).
Additional context
This possibly depends on #36 as otherwise it isn't possible to determine which resources are namespaced and which aren't, and the -n flag should not affect non-namespaced resources.
vsfedorenko
commented
3 years ago
Description of the problem/feature request
kube-linterassumes that objects that don't have a namespace specified aren't in any namespace. However, omitting the namespace from a namespaced object's metadata is not uncommon: in this case, the namespace is filled in to be the "current" namespace, as specified via the-n/--namespaceflag inkubectl,helmetc., or per the current context from the kubeconfig.kube-lintershould at a minimum support specifying the "current" namespace via an-nflag.Description of the existing behavior vs. expected behavior
Consider this YAML manifest consisting of a deployment, with an explicit namespace of "default", and a service with no namespace. In a standard kube environment, running
kubectl create -fon this file will expose the deployment via the service. However, when runningkube-linter lint <file> --do-not-auto-add-defaults --include dangling-service, the dangling-service check will trigger becausekube-linterattributes the service to<no namespace>.While it is accurate that it cannot be assumed for sure that both objects are in the same namespace, it should be possible to convince
kube-linterthat they are even without modifying the YAML file. For Helm charts, it's standard practice to omit the namespace object from the template in favor ofhelms-nparameter (see here).Additional context
This possibly depends on #36 as otherwise it isn't possible to determine which resources are namespaced and which aren't, and the
-nflag should not affect non-namespaced resources.