helm: don't warn about group/world-readable KUBECONFIG if it contains no secrets

I think that an environment variable to suppress these warnings is a cleaner approach than simply removing them. Something along the lines of SUPPRESS_KUBECONFIG_PERMS_WARNING or something explicit like that.

I’m upvoting this. Like (presumably) every other EKS user, my kubeconfig contains exec: command: aws args: --region BLAH eks get-token --cluster-name BLAH and no secrets whatsoever. I also have really good group-collaboration reasons why my group wants/needs to share their kubeconfigs with group permissions. This is not an “NTFS” thing, this is a deliberate, well-considered decision. I’d even go so far as to say that’s what group (or indeed world) permissions are FOR, isn’t it?

To be clear, will not accept PRs to suppress the security warning. This issue was pointed out by a security audit sponsored by the CNCF, and the warning was the security team’s recommendation.

Can we at least point out that the CNCF have been misled into thinking that this file is necessarily sensitive? Why NOT support an option in that kubeconfig to say something like “I hereby declare that this file is not secret or sensitive” for example? Give me the option to make it clear that this was a deliberate, well-considered decision.

My /etc/passwd file is also group/world readable. My /etc/shadow file is group (shadow) readable! I have group mailboxes which are deliberately group readable, and contain far more sensitive info than any of my kubeconfigs. C’mon, have some sense of proportion here.

Not stale, people again got bitten by this, see https://github.com/helm/helm/pull/12316#issuecomment-1732527352

@bigwheels16

I’m not sure why this is a problem. I don’t see what the big deal is inundating users with spurious warning messages

The problem is that the one who executes helm might be not a human, but another program. So this useless warning makes the subprocess running tough and ugly.