GitHub 操作 - 清空环境机密
GitHub Actions - empty env secrets
我已经开始玩 GitHub 操作,但我正在努力访问我作为 env 传递的存储库机密。
我的工作流程文件:
name: Invite
on:
pull_request:
branches: [master]
types: [closed]
jobs:
invite:
runs-on: ubuntu-latest
steps:
- name: Hello world action
uses: lekterable/inclusive-organization-action@master
env:
SECRET_TOKEN: ${{ secrets.SECRET_TOKEN }}
organization: string
SUPER_SECRET: ${{ secrets.SUPER_SECRET }}
动作索引文件
const core = require('@actions/core')
const github = require('@actions/github')
const run = async () => {
try {
...
console.log('env', process.env)
const token = process.env.SECRET_TOKEN
const secret = process.env.SUPER_SECRET
const organization = process.env.organization
console.log('organization', organization)
console.log('token?', !!token)
console.log('secret?', !!secret)
console.log('token length', token.length)
...
} catch (error) {
core.setFailed(error.message)
}
}
run()
如您所见,我传递了 3 个环境,值为 'string' 的组织按预期存在,但 SECRET_TOKEN 和 SUPER_SECRET 是空的。
是的,我确实在运行该操作的回购协议中设置了秘密:
我做错了什么吗?
更新
虽然下面的原始答案仍然适用于 public 存储库,但有几个 new updates 可能对某些用例有所帮助。
如果您的存储库是私有的,您现在可以 enable workflows 来自复刻。
如果您的存储库是 public,则有一个不受任何令牌限制的新 pull_request_target
事件。
原答案
您遇到此行为的原因是 Invite
工作流程是由来自分叉存储库的拉取请求触发的。
With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.
发生这种情况时,工作流的 actor
是打开拉取请求的用户。如果该用户没有对您的存储库的写入权限,则他们不能使用机密(GITHUB_TOKEN
除外)。
Anyone with write access to a repository can create, read, and use secrets.
如果您 运行 在您的工作流程中执行此步骤,您会发现它与您的操作无关。 TEST_SECRET
秘密在工作流程中也不可用。
- name: Test
env:
TEST_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
TEST_SECRET: ${{ secrets.TEST_SECRET }}
run: |
echo ${#TEST_GITHUB_TOKEN}
echo ${#TEST_SECRET}
检查 GitHub 上下文中的事件数据,您会看到 actor
是分叉存储库并打开拉取请求的用户。
- name: Dump GitHub context
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
This is a different but related issue 由 GitHub 工作人员回答,其中解释说,存在对分叉存储库的这些限制是为了“防止恶意行为者使用操作来毒害上游或下游存储库。”
我找到了一个解决方案,我所做的是解决它而不是 运行 关闭 PR 的操作我 运行 它是在 master 上的新提交上,这个必须由拥有 'write rights' 回购的人触发,因此,它可以访问回购秘密。
检查提交是否为合并提交有点困难,我们必须显式获取有关 PR 的更多信息,但它有效。如果有人感兴趣,我尝试构建的动作的源代码:https://github.com/lekterable/inclusive-organization-action
我已经开始玩 GitHub 操作,但我正在努力访问我作为 env 传递的存储库机密。
我的工作流程文件:
name: Invite
on:
pull_request:
branches: [master]
types: [closed]
jobs:
invite:
runs-on: ubuntu-latest
steps:
- name: Hello world action
uses: lekterable/inclusive-organization-action@master
env:
SECRET_TOKEN: ${{ secrets.SECRET_TOKEN }}
organization: string
SUPER_SECRET: ${{ secrets.SUPER_SECRET }}
动作索引文件
const core = require('@actions/core')
const github = require('@actions/github')
const run = async () => {
try {
...
console.log('env', process.env)
const token = process.env.SECRET_TOKEN
const secret = process.env.SUPER_SECRET
const organization = process.env.organization
console.log('organization', organization)
console.log('token?', !!token)
console.log('secret?', !!secret)
console.log('token length', token.length)
...
} catch (error) {
core.setFailed(error.message)
}
}
run()
如您所见,我传递了 3 个环境,值为 'string' 的组织按预期存在,但 SECRET_TOKEN 和 SUPER_SECRET 是空的。
是的,我确实在运行该操作的回购协议中设置了秘密:
我做错了什么吗?
更新
虽然下面的原始答案仍然适用于 public 存储库,但有几个 new updates 可能对某些用例有所帮助。
如果您的存储库是私有的,您现在可以 enable workflows 来自复刻。
如果您的存储库是 public,则有一个不受任何令牌限制的新
pull_request_target
事件。
原答案
您遇到此行为的原因是 Invite
工作流程是由来自分叉存储库的拉取请求触发的。
With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.
发生这种情况时,工作流的 actor
是打开拉取请求的用户。如果该用户没有对您的存储库的写入权限,则他们不能使用机密(GITHUB_TOKEN
除外)。
Anyone with write access to a repository can create, read, and use secrets.
如果您 运行 在您的工作流程中执行此步骤,您会发现它与您的操作无关。 TEST_SECRET
秘密在工作流程中也不可用。
- name: Test
env:
TEST_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
TEST_SECRET: ${{ secrets.TEST_SECRET }}
run: |
echo ${#TEST_GITHUB_TOKEN}
echo ${#TEST_SECRET}
检查 GitHub 上下文中的事件数据,您会看到 actor
是分叉存储库并打开拉取请求的用户。
- name: Dump GitHub context
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
This is a different but related issue 由 GitHub 工作人员回答,其中解释说,存在对分叉存储库的这些限制是为了“防止恶意行为者使用操作来毒害上游或下游存储库。”
我找到了一个解决方案,我所做的是解决它而不是 运行 关闭 PR 的操作我 运行 它是在 master 上的新提交上,这个必须由拥有 'write rights' 回购的人触发,因此,它可以访问回购秘密。
检查提交是否为合并提交有点困难,我们必须显式获取有关 PR 的更多信息,但它有效。如果有人感兴趣,我尝试构建的动作的源代码:https://github.com/lekterable/inclusive-organization-action