kube-client should hide exec functionality by default

[clux]

What problem are you trying to solve?

Want to avoid potential security advisories being landed against controllers built with kube that try to rely on local auth inside of a cluster. If those controllers are compromised then they can in theory be used as an escalation point.

Here is a security advisory for flux for allowing just that.

Describe the solution you'd like

Require some Config setting to explicitly enable Exec, and warn! when a kubeconfig is found with exec and it's not been enabled.

Not quite sure how best to disable Exec as it's an enum on RefreshableToken and it's kind of awkward to push that type of state in there. Maybe we can trim that bit out of the AutoInfo struct.

Thoughts welcome.

Describe alternatives you've considered

feature flags. not great, needs recompilation of apps.

Target crate for feature

kube-client

[kazk]

Maybe we can trim that bit out of the AutoInfo struct.

That should be pretty easy to do.

let mut config = Config::infer().await?;
// Set a field with `#[serde(skip)]` in `config.auth_info` to opt-in.
config.dangerous_auth_exec();

Then impl TryFrom<&AuthInfo> for Auth can check the flag, and either warn! + Ok(Auth::None) or Err(ExecDisabled).

[clux]

another option: if we can make the use of a local kubeconfig opt-in for in-cluster use, then the burden of sanitising will fall on the app.

that we we are not actually destroying all our examples for people who rely on this type of auth.

[nightkr]

Relying on the Kubeconfig itself to decide this would solve nothing, no?

The reasoning behind doing this makes sense, but it's awkward that this pretty much breaks any cluster that uses OAuth for authn.. :/

[clux]

Relying on the Kubeconfig itself to decide this would solve nothing, no?

yeah, it's a big if; it won't solve anything unless we have a foolproof way. i can't think of a good way to lock-out local authentication for in-cluster, unless we make local-auth a build flag.

[nightkr]

We could let users enable it via an env variable (in addition to the API, like we handle impersonation at the moment).

That still wouldn't help for cases where users load both a trusted and an untrusted Kubeconfig, but generally OAuth and other exec plugins should only be relevant during development anyway...