-
Notifications
You must be signed in to change notification settings - Fork 88
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
Proposal: kubelogin library usage #373
Labels
enhancement
New feature or request
Comments
This was referenced Dec 12, 2023
Giving no comments / objects raised in the past week, I will consider this proposal as accepted. Will work on this change this week. |
This was referenced Dec 18, 2023
PR for argo-cd: argoproj/argo-cd#16661 |
Closing this as we have published the library mode. Will continue work on the integration. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This proposal provides an overview of enabling kubelogin to be used as a library.
Background
There are a few asks on importing kubelogin as library from both internal and external users. The latest one is #371. Here is a list of known library imports (ref):
argocd-k8s-auth
crossplane provider-helm
The original design of kubelogin is to be consumed as a command line tool via the external credentials provider protocol. However, for 3rd party Kubernetes DevOps services, it's a common task to embed the same authentication flow into the product without the need of downloading kubelogin binary. In this case, we should enable the 3rd party service to import kubelogin as a library.
There are a few blockers for enabling this usage:
getToken
call is not being exposedTokenProvider
is returning legacyadal.Token
objecttoken.Options
exposes CLI usage settingsgetToken
call is not being exposedThe most needed feature is to generate a token using user environment input. We can do it via
getToken
call. However, this function is private to 3rd party library usage. We should expose this function along with the options structure.TokenProvider
is returning legacyadal.Token
objectEven though kubelogin is making use of
azidentity
internally, for local caching compatibility, thegetToken
function andTokenProvider
interface are still returning the legacyadal.Token
object. To avoid introducing legacy dependencies to 3rd party services, we should not expose this legacy interface anymore. Ideally, a string only representation should be used instead of pinning on a specific Azure SDK version as his approach can decouple the dependencies.token.Options
exposes CLI usage settingsThe current Options struct contains a long list of fields, some of them are for configuring CLI behavior, for example:
TokenCacheDir
). To avoid exposing unnecessary details, library usage should not allow users to consume these fields.Proposal
Goals
The goals for library mode as follow:
Azure/kubelogin
repository.Overview
We propose to convert the kubelogin module into this new project layout:
Implementations under the "exposed for library usage" section can be imported. Example usages:
GetAccessToken
Compatibility
Library users are expected to use the
pkg/token.Options
object for configuring the token retrieval behavior. This object will be converted into internal data models (for example,pkg/internal/token.Options
). Hence, there is no backward compatibility issue for this change. For future extension, we can add new optional fields to this object. This approach provides forward compatibility.Misc: Caching
Caching functionality is designed for CLI usage. In library mode, this functionality will be disabled by default. Library users can implement their own caching solution. If there is high demand for caching support, we can still expose it to library consumers in the future.
Conversion Steps
We expect to implement this change in following phases:
pkg
topkg/internal
cmd/kubelogin
packageTokenProvider
interface to return library agnostic token interfaceTokenOptions
object and export required types and constantskubelogin
version following semantic version best practiceMigration Steps For Existing Libraries
The text was updated successfully, but these errors were encountered: