Authentication renewal

[cben]

Some credentials have short shelf life. GCP auth is good for about a hour, I think(?). exec results may return expiration time, or may simply return error at some point.

Since one might have passed around a Kubeclient::Client object to many places,
it would be desirable to be able to renew auth - manually or automatically - without creating a new Client.

• TODO: study other libraries, notably the Go client.

[cben]

1. Mutable Client or external mutable object holding credentials?

Would a first step of making Client mutable, at least for auth_options, be helpful?
No. Presently you need separate Client object per API group, but you want to renew credentials only once. Having to keep track of each Client and patching them all would negate the gains.

Additionally, at least with some OIDC servers, refresh tokens are single-use (#409 (comment)), which is inherently messy across processes, but at least in one process, it's important to centralize renewal.

• Conclusion: we want a new object responsible for auth (not giving it a name yet).
  Many Client objects will be able to point to a single auth object.
• Conclusion: we want Client to ask the auth object for credentials before every API request.

[cben]

2. Will the current way users construct Client by passing in auth_options: config.context.auth_options etc. need to change?

Probably. We might be able to smuggle an auth object instead of passive data under a new key in auth_options, but not sure I want that.

Anyway, this will be a huge enough win to warrant an API change, I'm not worried about this for now 🙈

• BTW, credentials are not all in auth_options! Client certs currently go in ssl_options.client_cert, ssl_options.client_key. Not a big problem, just a point to keep in mind.

[cben]

Kubernetes plans to change service account tokens to short-lived: kubernetes/kubernetes#70679
This even simple in-cluster config will require on-the fly auth updates.