Open RedbackThomson opened 5 months ago
It would be great Argo CD to support the Kubernetes authentication mechanism using TokenRequest API to obtain short-lived API access tokens, which is the recommended way, instead of the legacy long-lived (non-expiring) persisted API tokens, generated by the control plane on the basis of created in advanced Secret with an annotation, referencing the ServiceAccount and respectively updated with that generated token data.
Summary
I'd like to support authentication to clusters through bearer tokens returned from a generic API call.
Motivation
Argo CD currently requires at least one username/password, bearer token, or exec provider config as authentication for clusters. None of these solutions provide a simple mechanism to retrieve short-lived credentials.
Username/password and bearer token methods query from long-lived credentials stored as secrets in the cluster. It is possible to rotate the credentials, but would require the use of an external controller to retrieve and swap the contents of the secret.
The exec provider config method is capable of retrieving short-lived credentials but relies on the user to mount an init container with the CLI tool so that Argo CD can call the executable from its
PATH
. While documentation for this feature is available, the process of adapting and deploying Argo with a custom container is complicated and error-prone, and becomes a large barrier to entry for some users.Assuming a user simply needs to query an API endpoint to retrieve short-lived credentials, it would be far simpler experience for them to provide a configuration defining the endpoint, it's input parameters, and it's output format instead of having to jump through the many hoops required by the current solutions.
Proposal
Full proposal document linked: https://github.com/argoproj/argo-cd/pull/18392