我正在探索使用 GitHub 容器注册表 (ghcr) 来存储在 GitHub Actions 中构建的持续集成 (CI) 管道中构建的 docker 映像。
我正在阅读迁移到 Docker 镜像的 GitHub 容器注册表，其中指出：
添加新的容器注册表身份验证个人访问令牌 (PAT) 作为 GitHub Actions 密钥。 GitHub 容器注册表不支持对 PAT 使用 GITHUB_TOKEN，因此您必须使用不同的自定义变量，例如
。CR_PAT
在那篇文章的前面，有一个链接到 GitHub Actions 的安全强化 其中指出：
您永远不应该使用自己帐户中的个人访问令牌。这些令牌授予您对您有权访问的组织内的所有存储库以及您的用户帐户中的所有个人存储库的访问权限。这间接向工作流所在存储库的所有写入访问用户授予了广泛的访问权限。此外，如果您稍后离开组织，使用此令牌的工作流将立即中断，并且调试此问题可能具有挑战性。
如果使用个人访问令牌，则它应该是为新帐户生成的令牌，该新帐户仅被授予对工作流程所需的特定存储库的访问权限。请注意，这种方法不可扩展，应避免使用替代方法，例如部署密钥。
这些引述似乎自相矛盾。第一个是告诉我在 CI 管道中使用 PAT 向 ghcr 进行身份验证，另一个似乎告诉我不应该。
我认为它们是矛盾的，是正确的还是我误解了？
从 GitHub Action 工作流程向 ghcr 进行身份验证的正确操作过程是什么？
它是两种说法的混合体。 您需要使用个人访问令牌 (PAT)，并且 GitHub Container Registry 不支持使用 GITHUB_TOKEN 作为 PAT，因此您必须使用不同的自定义变量，例如 CR_PAT。
您可以创建一个新的 GitHub 帐户，专门用于非人类自动化，例如 CI/CD。 由于这个 GitHub 帐户不会被人类使用，因此它被称为机器用户，并且受到 GitHub 服务条款的允许。 然后，您应该授予该计算机用户帐户完成其工作所需的最小权限。
如果您使用属于您的个人帐户而不是属于单独的最小权限机器帐户的 PAT，则存在令牌被其他人获取的风险，因此您的个人帐户及其所有权限都会受到损害（非常糟糕！）。当在一个有多名同事/合作者的组织中工作时，风险可能性更大。