Github-Action-Day11:密文 (Secrets)

这是我的 Github Action Advent Calendar 的第十一天的内容,如果您想要了解更多已经发布的 tips 信息,查看此处的 索引

昨天我们配置了一个基于路径更改而触发的工作流;这个工作流的目标是为了发布文档。如果你仔细观察的话,在这个工作流的底部,我们引用了一个变量。它和我们引用矩阵变量的方式很像,但其实是引用了一个密文 (secret) 。

在部属项目的场景中,您经常需要一些类似 token 和 passowrd 的东西,Github Action 支持它们以 secrets 的方式保存在您的仓库中。

如果要配置一个 secret 密钥,进入您的仓库设置页,然后选择 Secrets 该项。您的 secret 的名字将在您的工作流 (workflow) 中用于引用该 secret 的内容,而您可以在 value 栏中放置 secret 本身的内容。

Adding a secret

若要使用这个 secret,您可以在您的 workflow 中使用 secrets 上下文变量来引用它。假设您有一个名为 SECRET_KEY 的 secret,您可以使用 ${{secrets.SECRET_KEY}} 引用该 secret 的值:

GITHUB_TOKEN

在任意一个workflow 运行时,Github Action 都会在您的仓库自动设置一个名为 GITHUB_TOKEN 的 secret 密文。这个 token 使您无需创建一个新的 token 或者 secret 就可以直接和您的仓库交互访问。

这个 token 赋予您对这个仓库本身,仓库的 issue,仓库的 Github Package 进行有限的读写权限。但是它没有提供对于所有内容的完整访问权限 — 您无法操作在当前组织的其他仓库,也不能发布这个仓库到 Github Pages — 所以对于有些 workflows 来说,您依然可能需要配置一个 token。

Secret Safety

Github 试图使您的 secret 不被窥探。在输出的日志中,您定义的任何 secret 在日志输出前都会被擦除,并替换为 * 星号。

测试所用代码:

Leaked Secret

这可以帮助保护您的 secrets 不被窥探 — 特别是不被哪些抛弃价值观的工具所窥探。但是这个效果并不完美,当然,您自己也应该注意保护您的 secrets 。

Forks

如果您负责一个开源项目,您的项目使用 fork 来获取贡献者的 pull requests — 例如,如果您正在一个开源项目中工作,您可能需要谨慎地在您的工作流workflow 中使用 secret。

Github 明确禁止提供 secret 给 fork 后的项目中的 workflow (使用)。这意味着当一个用户从 **fork 的您的项目 **中开启了一个 pull request,这个 workflow 中不会有任何(原仓库中的) secret。

No Secret

这可以避免用户通过修改工作流 (workflows) 本身,或工作流 (workflow) 调用的任何脚本,以试图获取您的 secret 的复制副本。因为这些 secrets 根本就不存在。

(特殊的GITHUB_TOKEN 依然会提供于 fork 的项目中,以便他们构建项目时,可以 clone 您的仓库 — 但是在fork 的项目中,GITHUB_TOKEN 会降级为一个只读的 token ,防止 fork 的工作流修改您的原项目)