remove exec and auth provider check to utilize kubeconfig with oidc enabled

[neo-liang-sap]

What this PR does / why we need it:
In gardenctl there's validation against kubeconfig which doesn't allow kubeconfig contains exec or auth provider to prevent malicious executable code. Now with OIDC enabled, kubeconfig contains exec part, so i would like to propose this PR to discuss whether we can remove this check in gardenctl

Which issue(s) this PR fixes:
Fixes #217 and #175

Special notes for your reviewer:

/CC @dansible @ThormaehlenFred @DockToFuture @ialidzhikov @vpnachev @donistz

Basically this PR enables gardenctl to utilize oidc enabled kubeconfig, i did some basic testing like gardenctl target garden/seed/shoot and then do some kubectl operation like gardenctl k get pods -- -n kube-system etc , so far so good.

Indeed it is security to allow using kubeconfig with exec part which can execute any code, as discussed in https://banzaicloud.com/blog/kubeconfig-security/ (thanks for @DockToFuture ), we could discuss e.g. we add some warning message in gardenctl project regarding this? to let people know gardenctl allow using kubeconfig contains exec part which could be security risk....

Release note:

remove kubeconfig validation for exec and auth provider, to utilize kubeconfig with oidc enabled.

[petersutter]

I think it depends on whether the kubeconfigs are coming / are read from a trusted source.

• Is the garden landscape that you are targeting trusted?
• Have you got the kubeconfig for the garden landscape from a trusted source

If the above is true, we could assume that also the kubconfig secrets that we read from the gardener are safe. The gardener has implemented a validating webhook to validate secrets containing kubeconfigs

[DockToFuture]

Yes, I also agree with @petersutter here. It's always good to double check but I guess we gain more out of it if we leave it to the user to check the kubeconfig if it was not downloaded from a trusted source. What does the rest of you think any objections?

[neo-liang-sap]

thanks for your comments @petersutter @DockToFuture , i had another suggestion, if we could allow exec in kubeconfig utilized by gardenctl, maybe i can add some warning message when the validation hook found there's exec part in kubeconfig? say some warning message like Your kubeconfig contains exec part which could execute malicious code, please make sure your kubeconfig comes from trusted source.....

What do you think? if it's OK i will add these warning message to this PR

Thanks

[petersutter]

In case we want to display a warning message (do not have a strong opinion here)

• it should be clear which kubeconfig is meant, e.g.
  • local path of the downloaded kubeconfig
  • and/or by naming it like:
    • shoot kubeconfig for my-project/my-shoot
    • seed kubeconfig my-seed
    • garden kubeconfig xyz
• a warning of course only makes sense if the kubeconfig is not used (a kubectl command is run) before the user had the chance to acknowledge/read the warning

Your kubeconfig contains exec part which could execute malicious code[...]

nit: change to [...] could contain malicious code[...]

Other suggestion:
Kubeconfig for [...] under path [...] contains exec and or auth provider configurations that could contain malicious code. Please only continue if you have verified it to be uncritical

[neo-liang-sap]

i updated PR with warning message like this

[ThormaehlenFred]

/lgtm

[DockToFuture]

/lgtm, as discussed with @ThormaehlenFred there are no further concerns.