GitHub Release: Support AzurePipelines GitHub app for service connection

[jim-paton]

The Azure Pipelines GitHub app is now the recommended method for connecting Azure Pipelines and GitHub repos, however this task only supports authentication with OAuth or PAT.

[raiyanalam]

Thanks Jim for reaching out. The reason for current restriction is that the GitHub app token can potentially have access to repos that even the user doesn't have access to. This can have security implications. In the supported PAT/OAuth2 however, the permissions are scoped to the user who created it and hence is more secure. Having said that, we understand your concern. You will be glad to know that we are working towards dynamically scoped GitHub App token that will have access to only certain repos instead of all repos. Tentatively, we are looking at a timeline of 2-3 months for this to light up publicly.

[jim-paton]

Thanks. However, is that not the whole point of the GitHub app? My organisation has installed the Azure Pipelines GitHub app on the repos that they want available to the build/release pipelines. I understand that it's possible to install it for all repos, but surely that's a management issue? From the documentation (my emphasis):

To use the GitHub App, install it in your GitHub organization or user account for some or all repositories. Installation requires you to be a GitHub organization owner or repository admin.

After installation, the GitHub App will become Azure Pipelines’ default method of authentication to GitHub (instead of OAuth) when pipelines are created for the repositories. This is recommended so that pipelines run as “Azure Pipelines” instead of a user’s GitHub identity which may lose access to the repository.

[mbrancato]

I ran into this today and I too am confused. The UI doesn't allow specifying the Azure Pipelines service connection. That said, the GitHub App token is scoped to certain repos - that is controlled by the GH admin. The confusion is that someone with access to my project in DevOps already has access to use that service connection to private repos. So why is pulling data using the service connection accepted but pushing releases is not?

[mchippingtonderrick-afl]

I've encountered the exact issue described by the OP, and the response leaves me somewhat confused about what the intended usage method is supposed to be here.

What is the point of having the connection via the Pipelines GitHub App if we will need to set up additional separate connections to github to handle creating releases anyway?

[Trolldemorted]

@raiyanalam now almost 6 months have passed, can you give us an update on how this is supposed to work?

I have an organization which I'd like to push releases from azure pipelines to, but without giving access to all my other repositories.

[raiyanalam]

@romil07 is currently working on this. Adding him to provide updates, if any.

[TomBruyneel]

Any updates on this?

[romil07]

@TomBruyneel We did some work around this but we haven't published it. This is going to be a part of release 170.

Expect this to land in 3 weeks from now.

[bmw]

Any updates here?

I've been eagerly awaiting this feature for a while.

[softworkz]

The Azure Pipelines GitHub app is now the recommended method for connecting Azure Pipelines and GitHub repos, however this task only supports authentication with OAuth or PAT.

It hasn't clearly been stated here, so is my understanding correct, that it is currently impossible to create/publish a GitHub from Azure Pipelines, when the target repository belongs to a GitHub organization?

• GitHub App authentication is not supported (what this issue is about)
• It doesn't seem possible to create a PAT for a GitHub organization (when using a PAT for my personal account I don't see the organization's repos, even though I'm the owner)
• Same for OAuth

Am I missing something?

[travisgosselin]

I don't believe that the second bullet is accurate. Currently, I am using a personal account with a PAT that is a member of the organization, that has "ADMIN" access on a repo with this Task successfully. Not ideal though of course to use the PAT (may consider using a BOT account if not resolved soon to allow GitHub App authentication).

[softworkz]

I don't believe that the second bullet is accurate.

It doesn't seem possible to create a PAT for a GitHub organization

I meant for the organization itself.

Currently, I am using a personal account with a PAT that is a member of the organization, that has "ADMIN" access on a repo with this Task successfully. Not ideal though of course to use the PAT (may consider using a BOT account if not resolved soon to allow GitHub App authentication).

Thanks Travis - maybe it just doesn't work for the organization owner... I'll try to create a separate account.

[maxtheaviator]

Any news on the support of Github Organizations for the Task GitHubRelease@0 with an Azure Pipelines App installed with "Install Token"? This integration is managed by organization admins and scoped to the organization only.

Separate Service Connection doesn't work with OAuth due to Github "Restricted third-party application access".

For reasons stated above PATs aren't a thing I would like to use on an organization level and should be considered a workaround only. Developer PATs aren't limited to a repo but to the personal account. I don't see any security benefit to create a Service Connection with a PAT with Admin rights to all the repos - also private ones - I personally have and expose this to other Team Members in Azure DevOps.

Only solution would be a dummy account in Github someone needs to pay for only to be able to create a limited scoped PAT.

[wibblemonkey]

Today I had occasion to create my first new Azure Pipeline in a while and upon discovering that the Azure Pipelines GitHub App isn't supported in the GitHub Release task and that I'm expected to provide a PAT or OAuth token, I assumed that there must be an open issue to have this added - only to find that there is, and I raised it over two years ago! It looks like there have been a number of false starts on this but as it's now two years down the line, is there any chance of an update as to when this might finally be available?

[pulkitaggarwl]

@aaronhalberg to have a look at this one.

[ihnorton]

As far as I can tell, this means it is impossible to create a release task which is not tied to a specific user. The PAT solution above will stop working when the PAT creator loses permissions on the org.

This can cause release upload failures without any indication that auth is the underlying problem: https://github.com/microsoft/azure-pipelines-tasks/issues/15220 (debugging steps w/ curl posted in: https://github.com/microsoft/azure-pipelines-tasks/issues/14662#issuecomment-912675920)

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[CloudPlatformer]

@raiyanalam @romil07 Hi, is there an update on this? It would be great to remove all use of PAT/OAuth GitHub service connections within Azure DevOps.

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[bmw]

I'm still interested in this.

[marcjimz]

It's a shame this is still an issue. I'm unsure why it's so tightly coupled to the OAuth flow in enabling this as a service connection. We just migrated from Enterprise Server to Cloud (Github) and this is the biggest issue in our adoption for our platform plugins. Once an app is granted access, it should be able to assume the scoped permissions that it was approved for. We were able to do this in the enterprise version by use of service accounts and PAT, which none required user sign-in flow.

What can we do to move this forward?

[zoeperryman]

Just hit this issue today and a bit disappointed to discover this issue is nearly 4 years old with no substantial updates...

[jbrandt-mindex]

Bumpity-bump; following this as well. Not an ideal practice to tie a service-level system to a user-level access mechanism such as an OAuth token UNLESS a dedicated service user is created to represent Azure DevOps within a GitHub organization.

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[softworkz]

Still interested!

[m1nkeh]

I doubt this will ever be "fixed" it's clearly not a priority, or seen as a problem 🙁

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[softworkz]

..

[softworkz]

Not stale

[ChristopherMank]

Curious if we can get an update on this? While I'm not trying to use the GitHub Release task, I am running into the same issue that is preventing the GitHub Release task from being updated. That issue being what @raiyanalam first mentioned above, the token used by the Azure Pipelines GitHub App is fully scoped to the repos you have configured on that app. In the case of moving all your ADO repos to GH but keeping pipelines in ADO (for now), you would of course naturally have the GitHub app configured for all repos. However one could never configure your ADO pipelines or the GitHub Release task this way as it's a major security issue.

The alternative I suppose could be to use OAuth using a service account and then scoping the various ADO Service Connections, however this still poses a security risk and would require more GH licensing for service accounts.

Any thoughts on when we might see a dynamically scoped GitHub App token? Unless you had the correct ADO and GH topology (and it would be one that is not following any other best practice), I just don't see how this integration is usable in it's current form. Is there something I'm missing here?

@vijayma FYI