[RFC] Passwordless authentication for Git repositories #4114
Conversation
Signed-off-by: Sanskar Jaiswal <[email protected]>
| * `azure` | ||
| * `github` | ||
| * `gcp` |
There was a problem hiding this comment.
Why not OIDC? OIDC should be independent of any specific implementation/provider and provides proper discovery endpoints. This would open up many more integrations with the likes of Keycloak or Auth0.
There was a problem hiding this comment.
Which Git SaaS uses OIDC? GCP and AWS they don’t even support workload identity, GH uses the property GH App API.
There was a problem hiding this comment.
@makkes the goal here is to not support OIDC providers. the goal is to provide platform/cloud provider native auth mechanisms as an alternative to regular passwords.
There was a problem hiding this comment.
if you feel the RFC was not clear about this, kindly recommend suggestions that will make it clearer.
There was a problem hiding this comment.
GH uses the property GH App API
GitHub Apps is pretty much just an OAuth 2.0 (i.e. RFC 8628) mechanism.
This was a bit too simplified: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps
There was a problem hiding this comment.
One example: Gitea can act as an OAuth2 provider. During bootstrap the Flux CLI can redirect the user to the authentication page (pretty much like kubelogin does. That would allow Flux to support a much broader set of Git hosting implementations.
There was a problem hiding this comment.
GitHub Apps is pretty much just an OAuth 2.0 (i.e. RFC 8628) mechanism.
umm as far as i understand not quite. RFC 8628 requires the end user to navigate to a URL on the authorization server and enter a code presented by the client, an OTP of sorts. GitHub Apps just requires you to send a unique identifier, which is the JWT generated using the private key associated with the GitHub App to a URI for your installation ID which is (i assume) the client_id.
There was a problem hiding this comment.
@makkes i'm sorry if you misunderstood but this RFC is not about the CLI at all. its about users not having to put passwords in the cluster and having to manage them. adding support for OAuth2 as a part of the bootstrap process lies completely outside the scope of this RFC. out of the three providers this RFC proposes, only one (GitHub) is actually supported by bootstrap.
@makkes see the "Caching" section at the bottom. do you feel like that section does not contain enough info about handling of expiring tokens? what more would you like to see in the section? |
| * `azure` | ||
| * `github` | ||
| * `gcp` |
There was a problem hiding this comment.
One example: Gitea can act as an OAuth2 provider. During bootstrap the Flux CLI can redirect the user to the authentication page (pretty much like kubelogin does. That would allow Flux to support a much broader set of Git hosting implementations.
| 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 | ||
| self-expire, the cache shall automatically evict the token after it has expired, | ||
| triggering a fetch of a fresh token. |
There was a problem hiding this comment.
Why not make use of a refresh token here? Do the SaaS providers mentioned throughout this RFC support that?
There was a problem hiding this comment.
None of the mentioned providers support the refresh_token attribute.
- GitHub: https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app
- Azure: https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http
- GCP: A
TokenSourceautomatically handles the refreshing of an expired token, so we can just cache theTokenSourceobject and call.Token()on it to always get a valid token. This is what also Argo does: https://github.com/argoproj/argo-cd/blob/72754d772610636af95c030bc0f7608633a80896/util/git/creds.go#L539-L541
aryan9600
added
area/git
Signed-off-by: Sanskar Jaiswal <[email protected]>
pjbgf
changed the title
|
Is this still being planned? I'm very interested in being able to use managed identities for git instead of a manual step right now of adding a secret to my clusters. |
|
would also be interested in using Azure DevOps managed identities/service principals |
|
Would any of the maintainers sponsor this RFC? I would like to start making progress on this. |
Thanks for stepping up @bavneetsingh16. I volunteer to sponsor this RFC. |
|
Superseded by #4806 |
Is there another PR in flight for this or will it be implemented later then? |
First the RFC has to be agreed on and merged, then we can talk about implementations. I've added the RFC to the roadmap but it all depends on the availability of those involved. |
This RFC proposes adding support for passwordless authentication for Git repositories on Git SaaS platforms and cloud providers using methods like OIDC, OAuth2 and IAM.