Giters

nolar / kopf

A Python framework to write Kubernetes operators in just a few lines of code

Home Page:https://kopf.readthedocs.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add login_via_kr8s() auth piggyback backend

jacobtomlinson opened this issue · comments

commented

Problem

Today I was playing around with writing an example controller that uses kopf with kr8s.

I noticed that in the container I was building, kopf was falling back to it's own built-in authentication which is only recommended for use in trivial cases.

kopf/kopf/_core/intents/piggybacking.py

Lines 208 to 209 in 91e8fd6

This login function is intended to make Kopf runnable in trivial cases
when neither pykube-ng nor the official client library are installed.

This is happening because kopf tries to piggyback on kubernetes or pykube-ng for auth but I didn't have either of those libraries installed.

Proposal

I would be happy to contribute a login_via_kr8s() piggyback backend so that kopf reuses the auth from kr8s when only those two libraries are installed.

It looks like I would need to implement has_kr8s() and login_via_kr8s() in kopf/_core/intents/piggybacking.py and then call it in kopf/_core/intents/registries.py::SmartOperatorRegistry.

Is there anything else I would need to do to get things working?

Code

No response

Additional information

No response

commented

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).

commented

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.

commented

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!