Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add login_via_kr8s() auth piggyback backend #1081

Open
jacobtomlinson opened this issue Dec 12, 2023 · 3 comments
Open

Add login_via_kr8s() auth piggyback backend #1081

jacobtomlinson opened this issue Dec 12, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@jacobtomlinson
Copy link

jacobtomlinson commented Dec 12, 2023

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.

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

@jacobtomlinson jacobtomlinson added the enhancement New feature or request label Dec 12, 2023
@nolar
Copy link
Owner

nolar commented Dec 12, 2023

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

@jacobtomlinson
Copy link
Author

jacobtomlinson commented Dec 13, 2023

Thanks @nolar!

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

Kr8s supports the following auth methods:

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.

@nolar
Copy link
Owner

nolar commented Dec 13, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants