Support GitHub App authentication

[joebowbeer]

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

argoproj/argo-cd#3086

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.

argoproj/argo-cd#4348

[thockin]

I need less "why" and more "what" and "how". I have no context or ability to test.

[joebowbeer]

@thockin Implementations exist in the jenkins and argocd repos. I'll try to dig out more details.

[mcfearsome]

@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.

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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-ci-robot]

@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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

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.

[samirtahir91]

@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

[thockin]

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.