Ergonomic service account impersonation

[nightkr]

Would you like to work on this feature?

No response

What problem are you trying to solve?

When developing an operator I usually just run it locally, which means that it runs as my K8s user, which usually has more permissions than the operator itself does.

This makes it easy to screw up the RBAC permission manifest, because I made a typo or forgot to update it when adding a new feature that requires a new permission.

Describe the solution you'd like

Config::infer() should read an environment variable (maybe KUBE_RS_IMPERSONATE) that overrides AuthInfo::impersonate when applying the config.

Describe alternatives you've considered

I could apply this statically to my kubeconfig, but then that applies to all tools (including kubectl), which would make it more annoying to debug what's going on.

I could also make sure to only test stuff in-cluster, but depending on the specific app this might have unacceptable container build overhead.

Documentation, Adoption, Migration Strategy

We should probably document in Config::infer, (and maybe for Api and Client) that they can run their app as KUBE_RS_IMPERSONATE=system:serviceaccount:default:foo cargo run to impersonate the service account foo, but that this should only be used for development.

There is no migration required for users who don't want the feature.. just don't use it.

Target crate for feature

kube-client

[clux]

So this would replicate behaviour in kubectl {args} --as=superman --as-group=system:masters (which afaikt just ends up in their transportConfig).

This seems reasonable to me as long as it in theory can cover the same surface as --as and --as-group does in isolation.

Personally, I think it's a nicer suggestion than using args to kubectl because you can put it in env configs when you are developing. 👍

[nightkr]

Yeah.. we also don't own arg parsing, so we can't hook into that as transparently.