Add login_via_kr8s() auth piggyback backend about kopf HOT 3 OPEN

Thank you! So, there are a few methods beyond the trivial config file. That, combined with its popularity, is a good reason to support kr8s out of the box. A PR would be highly welcome!

from kopf.

Hello. No, doing the same as for pykube-ng would be sufficient.

For context: pykube-ng (ex-pykube) is there mostly for historic reasons: at some point, Kopf used it as an API client (before switching to requests, then to aiohttp), so it was left for backward compatibility.

Overall, I prefer not to overcomplicate Kopf's code except for the major widely used libraries, such as the official k8s client, so I am conservative here. But I would prefer it even more not to turn Kopf into a K8s API client, so it is better to delegate all the auth job to other libraries for cases beyond simple reading of the kubeconfig file "as is" (e.g. all the interactive token retrieval, live token rotation/refresh, encryption/decryption, so on).

Kr8s seems to be popular enough to add it out of the box, so this criterion is satisfied. Can you please summarize, which auth methods it has beyond the trivial ones? If there are some, its support can be added to Kopf.

PS: If sending a PR, please add thorough tests for it too — the same as for pykube-ng & the official client (with and without the module installed, as simulated by pytest fixtures).

from kopf.

Thanks @nolar!

Can you please summarize, which auth methods it has beyond the trivial ones?

Kr8s supports the following auth methods:

• Client certificates
• Tokens
• Exec with rotation/refresh (seems to be very popular these days with hosted Kubernetes)
• OIDC (refresh coming soon kr8s-org/kr8s#125)
• Username/password (this was removed in Kubernetes 1.19 and will be removed from kr8s kr8s-org/kr8s#240)

Note that kr8s doesn't support the legacy auth-provider methods other than OIDC which have been removed in upstream Kubernetes in favour of exec.

from kopf.