Authenticate as Github App

[tenjaa]

Hi, we would love to use this resource but have a small problem with the authentication. We do not want to generate a personal access token as that would give anyone with access to the pipeline access to all repos of the creator. We know about the pattern of machine users, but we are encouraged to not use external collaborators in our org. Therefore we looked for other ways:

I read through the Github docs and as far as I understood that there is a way to generate an access token as a Github App. https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation Do you know if that is the same access token as a personal one?

So do you think it would be possible for us to create a Github App, install it to our repos and then just provide the client-id and client-secret to use it? This resource would need to generate an access token and then can work as it did before.

Obviously this would need a pull request, but I think we might be able to provide that.

What do you think?

[rickardl]

First, thank you for your contribution.

For me, personally I'm not sure if this resource should be directly integrated as an application, @itsdalmo might have a better method explaining the vision, but we try to keep the moving parts to a minimum.

We don't typically use a PAC from "service accounts", our internal integrations also utilizes a private GitHub application but as a separate entity (e.g. https://github.com/telia-oss/sidecred, the deployment doesn't depend on it being a lambda, there's a native CLI for it also), which grants a method to generate short-lived credentials (selectively an access-token or deploy key, with variable duration) and exposes them as secret variables for Concourse tenants.

This provides an easy integration to the teams in Concourse, using the Secrets backend, it allows teams one or more variably installed (private, or public) GitHub application and selectively use them within organizations (private ones can't be shared), with the added benefit of a method to provide unique credentials, even though it targets the same repo.

Would that method, mitigate your need for this?

[tenjaa]

Unfortunately no. Due to how it is organized we cannot install some modifications to our concourse.

I understand your point. The best solution is probably something like var_sources in combination with prototypes.

We started using my fork, so I guess Ill just maintain it until we get a better solution from concourse directly. It shouldnt be too hard to keep it in sync with some github action. I just saw https://github.com/telia-oss/github-pr-resource/pull/228 and then even running tests on my side should be doable. :) Feel free to close this and the PR

[rickardl]

I understand your pretext, since the solution technically allows for a PAC to be used, regardless of our intention that people should probably not implement it that way, it might be the most common option.

Denying the use of a GitHub application, with private keys, might be a bit misguided from our side, but wouldn't an option be for you to perhaps provide a resource that can fetch your required credentials (access-tokens)? I'm sure you could borrow some of the work like this we've been doing to make some sort of JIT version of sidecred?

Regardless, it would be great if other users would like to chirp in on this, I'm willing to have an open mind because it's very much a community effort.

[tenjaa]

Well we (or I in that context) built that already: https://github.com/tenjaa/concourse-github-app-token But how do I use that token for your resource without var sources / prototypes? That is not possible yet, is it?