CODEWITHSUNDEEP
gitgithuboauthgithub-api
Bounce2thaOunce
Bounce2thaOunce

Reputation: 1371

GitHub OAuth2 Token: How to restrict access to read a single private repo

Use-case:

  1. Command-line application (which is deployed to a 3rd party machine) needs to be able to download a tarball copy of a private repo that belongs to an organization via the GitHub API (v3)

  2. Application should only be able to access this one private repo and no other repos with read-only permission.

I have been able to accomplish (1) by creating an authorization for the application after registering a client_id/secret on my github account. However, it does not seem that the tokens returned by the authorization allow read-only access to the repo nor are they restricted to one repo (e.g. one could potentially use the token to modify this repo along with others belonging to the organization).

Is it possible to restrict access via the proper scope? I don't see anything relevant in the API docs (https://developer.github.com/v3/oauth/#scopes).

Upvotes: 137

Views: 54489

Answers (5)

Krzysiek
Krzysiek

Reputation: 2495

Update

Github finally introduced fine-grained personal access token, this (or Machine user) should be now a preferred method for granting selective access.

Read more: https://github.blog/changelog/2022-10-18-introducing-fine-grained-personal-access-tokens

Original answer

I wanted to have better access control in my Github Actions, but also have access to multiple repositories at the same time. And sure enough Deploy Keys are way to go. You can choose read/write permissions, but unfortunately you need a new pair for every new repository. Bellow I'll show you how I made it to work.

Let's assume you need to access 2 repositories from the third running Github Actions

  • Generate your keys 
    ssh-keygen -N '' -t ed25519 -C "First Key Name" -f ./first_key
ssh-keygen -N '' -t ed25519 -C "Second Key Name" -f ./second_key
    You don't need a passphrase as long as you'll remove keys from the filesystem after adding them to the secrets in the Github repository.
  • Add contents of *.pub files as Deploy keys of respective repositories (select write permissions if needed)
  • Add contents of first_key and second_key files to third repository's secrets as DEPLOY_KEY_FIRST and DEPLOY_KEY_SECOND respectively
  • Now you can remove generated key files - you don't want to keep them around anymore. You can always generate a new ones.
  • Setup workflows file 
    name: Some automatic action

on:
  # on push event
  push:
  # allow manual run
  workflow_dispatch:

env:
  # sockets for multiple ssh agents (1 per key)
  SSH_AUTH_SOCK_FIRST: /tmp/ssh_agent_first.sock
  SSH_AUTH_SOCK_SECOND: /tmp/ssh_agent_second.sock

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # first step is to setup ssh agents
      - name: Setup SSH Agents
        run: |
          # load deploy keys from the secrets
          echo "${{ secrets.DEPLOY_KEY_FIRST }}" > ./ssh_key_first
          echo "${{ secrets.DEPLOY_KEY_SECOND }}" > ./ssh_key_second

          # set chmods (required to use keys)
          chmod 0600 ./ssh_key_*

          # start agents
          ssh-agent -a $SSH_AUTH_SOCK_FIRST > /dev/null
          ssh-agent -a $SSH_AUTH_SOCK_SECOND > /dev/null

          # add each key to their own ssh agent
          SSH_AUTH_SOCK=$SSH_AUTH_SOCK_FIRST ssh-add ./ssh_key_first
          SSH_AUTH_SOCK=$SSH_AUTH_SOCK_SECOND ssh-add ./ssh_key_second

          # you can now remove keys from the filesystem
          rm -f ./ssh_key_*

      # now you can use these keys in normal git commands
      - name: Clone first
        env:
          # assign relevant agent for this step
          SSH_AUTH_SOCK: ${{ env.SSH_AUTH_SOCK_FIRST }}
        run: |
          git clone [email protected]:user/first.git ./first

      - name: Clone second
        env:
          SSH_AUTH_SOCK: ${{ env.SSH_AUTH_SOCK_SECOND }}
        run: |
          git clone [email protected]:user/second.git ./second
  • Profit

Disclaimer

As you may guess above solution is not scaling up, and at some point you may consider setting up a Machine user (suggested in starwed's answer), which works best with organization account (even free) and gives access to Personal Access Tokens and OAuth.

Upvotes: 9

VonC
VonC

Reputation: 1323095

This should now (Oct. 2022) be possible with:

Introducing fine-grained personal access tokens (Oct. 2022)

Today we're enabling fine-grained personal access tokens (PATs) in Public Beta for all user accounts on GitHub.com.
This new type of token gives developers and resource owners more control and visibility around token access.
Learn more about this new token type in today's blog post.

These new tokens offer many more permissions to choose from, must be scoped to a specific organization or account, and must expire.
Organization owners will also find new tools to manage tokens that can access their organization, and can require approval of those tokens before they may be used.

https://i0.wp.com/user-images.githubusercontent.com/1666363/196268191-dd27554f-746e-45cf-9b92-a62f1846cd9e.gif?ssl=1 -- PATsv2-light2

You can try out the new token creation flow, and provide feedback in our community discussion.

For more information, see "Creating a fine-grained personal access token".

This allows to select a specific repository, if you want to.

Upvotes: 1

alphabet5
alphabet5

Reputation: 1152

As the top answer has suggested this is currently not possible with GitHub.

It is not a direct answer to your question, but the reason I was looking to do the same thing was to abide by policy of only allowing TCP 443 outbound from a restricted zone.

GitHub accepts SSH on TCP 443 as documented here.

TLDR: If you modify your ssh from ssh://[email protected] to ssh://[email protected]:443 it should be successful.

To set github to use TCP443 in your SSH configuration file, edit the file at ~/.ssh/config, and add this section:

Host github.com
Hostname ssh.github.com
Port 443
User git

You can test that this works with:

$ ssh -T [email protected]
> Hi username! You've successfully authenticated, but GitHub does not
> provide shell access.

Upvotes: 0

starwed
starwed

Reputation: 2607

I don't believe you can restrict github OAuth tokens in that way. The github docs for OAuth say that

While Git over HTTP with OAuth reduces friction for some types of applications, keep in mind that unlike deploy keys, OAuth tokens work for any repository for which the user has access.

So while you can limit the scope of the token in terms of the types of activities, you can't limit it to a subset of repos.

Deploy keys can be restricted to a single repo, but allow write access.

The obvious tactic (as mentioned by Thomas) is to create a dummy account that represents the application. Given the goals of OAuth, this might be a better workflow in any case -- it'll let you easily change the permissions the app has as if it were in fact a user.

Github even mentions/endorses this strategy explicitly, calling them machine users.

Upvotes: 69

Sebastiaan
Sebastiaan

Reputation: 1130

Deploy keys are the way to go.

By default they don't allow write access and they are scoped to the specific repository (unlike the GitHub personal access token). So you can now generate a private/public key pair, set one as read/pull only deploy key on a single repository in GitHub and use the private key in your CI.

For instance run a bash script:

eval "$(ssh-agent -s)";
ssh-add <your private deploy key>;

Now your CI has rights to access private repo's during the build.

You can add a Deploy key by going to your repository on Github and then clicking Settings > Deploy keys > Add deploy key

Upvotes: 18

Related Questions