actions/fluxcd-flux2
3
0
Fork 0
mirror of https://github.com/fluxcd/flux2.git synced 2026-02-07 16:27:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

rfc: add more details around token refreshing and caching

Browse source 
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
This commit is contained in:
Sanskar Jaiswal 2023-08-02 12:46:05 +05:30
parent e3f6b242ea
commit 067180b5b2
No known key found for this signature in database
GPG key ID: 5982D0279C227FFD
1 changed files with 14 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
rfcs/0006-git-repo-passwordless-auth/README.md
View file

@ -186,13 +186,24 @@ token](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-
This token is then used as the password and [`x-access-token` as the username](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app#choosing-permissions-for-git-access)
to perform HTTP basic authentication.
### Caching
### Token Caching and Refreshing
To avoid calling the upstream API for a token during every reconciliation, Flux
controllers shall cache the token after fetching it. Since GitHub and GCP tokens
controllers shall cache the token after fetching it. Since GitHub tokens
self-expire, the cache shall automatically evict the token after it has expired,
triggering a fetch of a fresh token.
For GCP, the [`TokenSource`](https://pkg.go.dev/golang.org/x/oauth2@v0.10.0#TokenSource)
object will be cached, since it automatically handles refreshing an expired
token and always returns a valid token. Since a `TokenSource` never expires, it
need not be evicted from the cache.
While Azure's managed identities subsystem caches the token, it is
[recommended for the consumer application to implement their own caching](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token#token-caching)
as well.
The caches for all three providers are separate, i.e. there shall exist a
dedicated cache for each provider.
Since the proposed authentication methods for GitHub and GCP involve some form
of credentials stored in a Kubernetes Secret, the cache key can be the Secret's
`<namespace/name>`. Since authentication for Azure is configured directly via
the source-controller Deployment, the token can just be stored in a global
variable, which is refreshed whenever the token expires.