GitHub OAuth2令牌:如何限制读取单个私有仓库的访问权限

Question

用例:

1. 命令行应用程序(部署到第三方机器)需要能够通过GitHub API(v3)下载属于组织的私有仓库的tarball副本

2. 应用程序应该只能访问这个私有仓库,而不能访问具有只读权限的其他仓库.

我已经能够通过在我的github帐户上注册client_id/secret后为应用程序创建授权来完成(1).但是,授权返回的令牌似乎不允许对repo进行只读访问,也不限于一个repo(例如,一个repo可能会使用该令牌来修改此repo以及属于该组织的其他repo).

是否可以通过适当的范围限制访问？我没有在API文档中看到任何相关内容(https://developer.github.com/v3/oauth/#scopes).

Answer 1

我不相信你可以用这种方式限制github OAuth令牌.OAuth的github文档说明了这一点

虽然使用OAuth的Git over HTTP可以减少某些类型应用程序的摩擦,但请记住,与部署密钥不同,OAuth令牌适用于用户有权访问的任何存储库.

因此,虽然您可以根据活动类型限制令牌的范围,但您不能将其限制为repos的子集.

部署密钥可以限制为单个存储库,但允许写访问权限.

显而易见的策略(如Thomas所述)是创建一个代表应用程序的虚拟帐户.考虑到OAuth的目标,无论如何这可能是一个更好的工作流程 - 它可以让您轻松更改应用程序拥有的权限,就像它实际上是用户一样.

Github甚至明确地提到/赞同这个策略,称他们为机器用户.

Answer 2

部署密钥是必经之路。

默认情况下，它们不允许写入访问，并且它们的范围仅限于特定存储库（与 GitHub 个人访问令牌不同）。因此，您现在可以生成私钥/公钥对，将其设置为 GitHub 中单个存储库上的只读/仅拉部署密钥，并在 CI 中使用私钥。

例如运行 bash 脚本：

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

现在，您的 CI 有权在构建期间访问私有存储库。

您可以通过转到 Github 上的存储库，然后单击“设置” > “部署密钥” > “添加部署密钥”来添加部署密钥

Answer 3

更新

Github 最终引入了细粒度的个人访问令牌，这（或机器用户）现在应该是授予选择性访问的首选方法。

了解更多：https ://github.blog/changelog/2022-10-18-introducing-fine-grained-personal-access-tokens

原答案

我希望在我的Github Actions中有更好的访问控制，但也可以同时访问多个存储库。果然，部署密钥是可行的。您可以选择读/写权限，但不幸的是，每个新存储库都需要一对新的权限。下面我将向您展示我是如何让它发挥作用的。

假设您需要从第三个正在运行的 Github Actions 访问 2 个存储库

• 生成您的密钥

  ssh-keygen -N '' -t ed25519 -C "First Key Name" -f ./first_key
  ssh-keygen -N '' -t ed25519 -C "Second Key Name" -f ./second_key
  

  只要将密钥添加到 Github 存储库中的机密后将其从文件系统中删除，就不需要密码。
• 添加文件内容*.pub作为相应存储库的部署密钥（如果需要，请选择写入权限）
• first_key将和文件的内容分别添加到second_key第三存储库的秘密中DEPLOY_KEY_FIRSTDEPLOY_KEY_SECOND
• 现在您可以删除生成的密钥文件 - 您不想再保留它们了。您始终可以生成新的。
• 设置工作流程文件

  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 git@github.com:user/first.git ./first
  
        - name: Clone second
          env:
            SSH_AUTH_SOCK: ${{ env.SSH_AUTH_SOCK_SECOND }}
          run: |
            git clone git@github.com:user/second.git ./second
  

• 利润

免责声明

正如您可能猜测的那样，上述解决方案并未扩大规模，在某些时候您可能会考虑设置一个机器用户（starwed 的答案中建议），它最适合组织帐户（甚至免费），并提供对个人访问令牌和 OAuth 的访问权限。