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

[PR] Custom authentication methods #226

Closed
2 tasks
kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Closed
2 tasks

[PR] Custom authentication methods #226

kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Labels
archive enhancement New feature or request

Comments

@kopf-archiver
Copy link

kopf-archiver bot commented Aug 18, 2020

A pull request by nolar at 2019-11-12 12:08:27+00:00
Original URL: zalando-incubator/kopf#226
Merged by nolar at 2019-11-13 10:26:34+00:00

@on.login() handlers and arbitrary credentials for HTTPS requests (beyond those supported by the client libraries).

Issue : #187

Description

This PR adds @kopf.on.login handler for custom authentication methods. The handler should return either nothing (None) -- and it will be ignored, or an instance of kopf.ConnectionInfo. See the docs and examples in this PR.

Multiple login handlers can be declared. In that case, the returned credentials will be selected randomly.

The returned connection info items are then used in the API calls. Once they become invalid, all API calls freeze, and a re-authentication cycle starts. Once new credentials are retrieved, the API calls un-freeze and continue with the new credentials. If there are no new credentials retrieved, and all of the old ones are not valid anymore, the operator fails with HTTP 401 exception as it would otherwise do.

If errors happen in the login handlers, they will be retried as any other handlers. Sync/async handlers are also fully supported.

The kopf.ConnectionInfo objects have a priority -- in case some credentials are more preferred than the others, but the others are still needed as a fallback in the more preferred credentials become invalid.


Kopf piggybacks pykube-ng and kubernetes (if they are installed) for the purpose of authentication. Specifically, for the complex token retrieval schemas such as GKE or EKS or any other "auth-providers" as defined in the Kopf config files.

This ensures the backward compatibility -- it behaves (or should behave) the same as when pykube-ng's KubeConfig was used directly.

pykube-ng is still a required dependency, as the library itself is used as a client from the reconstructed KubeConfig objects. This will be changed when Kopf switches to aiohttp, and pykube-ng is left optional only for the authentication piggybacking.


Note: kopf.login() function is kept for backward compatibility and behaves same as before. However, it is not needed anymore, as the authentication (both initial and re-) is now part of the operator's task.

See the list of commits for detailed step-by-step changes.

Types of Changes

  • New feature (non-breaking change which adds functionality)
  • Configuration change

Review

List of tasks the reviewer must do to review the PR

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

No branches or pull requests

0 participants