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

时间:2014-10-15 00:06:16

标签: git github oauth github-api

使用情况:

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

    < / LI>
  2. 应用程序应该只能访问此私有仓库,而不能访问具有只读权限的其他仓库。

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

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

3 个答案:

答案 0 :(得分:24)

我不相信你可以用这种方式限制github OAuth令牌。 github docs for OAuth

  

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

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

Deploy keys可以限制为单个仓库,但允许写入权限。

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

Github甚至明确地提到/赞同这个策略,称他们为machine users

答案 1 :(得分:2)

部署密钥是必经之路。默认情况下,它们不允许写访问。因此,您现在可以生成一个私钥/公钥对,将其中一个设置为在GitHub中的单个存储库上读/拉仅部署密钥,并在CI中使用私钥。

例如,运行bash脚本:

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

现在,您的CI有权在构建过程中访问私有存储库。

答案 2 :(得分:2)

我希望在我的 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 文件的内容添加为各个存储库的 Deploy 密钥(如果需要,请选择写入权限)
  • first_keysecond_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
    
  • 利润

免责声明

正如您可能猜到的,上面的解决方案并没有扩大规模,在某些时候您可能会考虑设置一个 Machine user(在 starwed 的答案中建议),它最适合组织帐户(甚至免费)并可以访问个人访问令牌和 OAuth。