could you give the security risks of those checks about kube-linter

[kreamkorokke]

Hi @JacksonRin I think for some checks the remediation column does have links to further details, which might give more context on how and why the implemented checks are useful. We are also planning on adding some tests with sample input yaml files that would trigger these defaults checks, which could maybe help to understand the implications of checks as well.

As for the reasons we chose these checks to start with, we are starting with some commonly observed security pitfalls among k8s manifests. It is a growing set and we do plan to include more to help make this linter more robust.

[viswajithiii]

@JacksonRin To add to what Koki said, you can also find read more about these (and other) security best practices for Kubernetes in a wiki that we maintain at https://www.stackrox.com/wiki/.

[JacksonRin]

there is a specific question of env-var-secret check.
I've read the refer link:https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets,but I still can not find out why the pod should use secret file instead of env,so I am confused yet

[viswajithiii]

there is a specific question of env-var-secret check.
I've read the refer link:https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets,but I still can not find out why the pod should use secret file instead of env,so I am confused yet

@JacksonRin Sorry for missing this. To clarify, it is okay to use secrets in an environment variable as long as you reference a Kubernetes secret and use envFrom as the value. However, putting a environment key value pair directly in the deployment (for example: key: AWS_SECRET_KEY and value: s2f121qf12521gq) is insecure, because it will show up as part of the deployment spec, which is not guarded closely by Kubernetes at all, and is accessible in a wide variety of locations by default. Hope that helps!