Use the TokenRequest API to support >=1.24 clusters

[crenshaw-dev]

Summary

2.4 creates a non-expiring ServiceAccount token Secret on argocd cluster add for 1.24 clusters.

Instead, Argo CD should use the TokenRequest API.

Motivation

Kubernetes recommends using the TokenRequest API rather than relying on tokens that don't expire.

[danielhelfand]

Throwing in some notes I kept while implementing the CLI fix: https://docs.google.com/document/d/1MmYIfM8tbEp2irCaLtgrv9jJL-coYG3u-wa3xTVkEOU/edit#heading=h.r5wcd4iwxat8

Kubernetes has a TokenManager concept that creates, refreshes, caches, and rotates tokens from the TokenRequest API. The challenge right now is that some of clusterauth package's funcs are called directly by the argocd CLI, which doesn't allow Argo CD to persist token management. It might make sense to inject this token manager into the cluster server to add support for the TokenRequest API to avoid using these long lived tokens.

[mabhi]

Hi @crenshaw-dev , I am working on this issue. Would be raising a PR soon

[mabhi]

Hi @crenshaw-dev,
With reference to the document shared by @danielhelfand, while implementing the token request api in argocd-server, the decision whether to go for existing token generation old way or the using the new api in the code should come from ENV of the argocd-server or this can also be overriden with flags ?
What do you recommend here

[mabhi]

Hi @crenshaw-dev
While working on the enhancement, I came across few scenarios for which answers from your end would help.
I have the following questions:

1. Can a cluster user with the certificates be able to create/refresh the service account tokens?
2. Should a cluster user with a valid bearer token be the only one to create/refresh the service account tokens?
3. Should an error message be displayed if a cluster user with an expired bearer token tries to create/refresh the service account tokens?