Support GitHub App authentication
joebowbeer opened this issue · 9 comments
Instead of using username, password/token or ssh deploy keys.
It would be nice to support GitHub apps.
Revives #450
Inspired by
https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#github-app-repositories
https://github.com/jenkinsci/github-branch-source-plugin/blob/master/docs/github-app.adoc
Why?
- the rate limit for a GitHub app scales with your organization size, whereas a user based token has a limit of 5000 regardless of how many repositories you have,
- for organization’s that have 2fa enforced - no need to manage 2fa tokens for a 'bot' user
- to improve and tighten security: the Jenkins GitHub app requires a minimum, controlled set of privileges compared to a service user and its personal access token which has a much wider set of privileges
When syncing multiple private repositories, the current options are:
- Create a deploy key for each repository and upload them to argocd (hard to manage)
- Create a user for argocd (expensive, as you need to pay for a seat in the organization).
GitHub Apps also provide a far greater rate limit, have fine grained access control and as a huge plus, you don't even need to manage users for it.
I need less "why" and more "what" and "how". I have no context or ability to test.
@thockin Implementations exist in the jenkins and argocd repos. I'll try to dig out more details.
@thockin in short, the token returned by https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app#generating-an-installation-access-token can be used as the password with a username of git.
@joebowbeer that said you should be able to easily generate this response on your own and then pass it along to git-sync. That's my plan. Use a CronJob to keep a secret updated and my git-sync usage is already in a Job resource so its just a matter of consuming the secret the Cron is keeping updated for you.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@thockin in short, the token returned by https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app#generating-an-installation-access-token can be used as the password with a username of git.
@joebowbeer that said you should be able to easily generate this response on your own and then pass it along to git-sync. That's my plan. Use a CronJob to keep a secret updated and my git-sync usage is already in a Job resource so its just a matter of consuming the secret the Cron is keeping updated for you.
I also had this use case so I wrote an operator to do this as well as capability to rollout/upgrade deployments referring to the secret, feel free to use it https://github.com/samirtahir91/github-app-operator
Thanks! That code does a good job illustrating how to retrieve a short-lived token, given a long-lived private key.
I would still consider adding this to git-sync, but I personally do not have the time to do the work right now. If someone is interested in implementing, I am happy to talk thru a design that I would think fits. Or people can use this operator - it seems like a reasonable approach, albeit more flexible than git-sync itself needs.