docker - Jib:如何在不安装的情况下使用 amazon-ecr-credential-helper？

Question

使用 jib-gradle-plugin 时要构建并推送到 AWS ECR，我需要安装 aws ecr credential helper否则构建会提示“系统没有 docker-credential-ecr-login CLI”。
我想知道是否有一种方法可以在不安装凭证助手的情况下推送到 AWS ECR，或者是否可以在存储库中捆绑可移植版本的凭证助手？
安装助手的问题是:

它需要在需要构建项目的每台机器上安装帮助程序，因此使构建流程不像我想要的那样自动化

要安装 aws ecr 凭证帮助程序，需要安装 Docker .这感觉有点讽刺，因为 Jib 的很大一部分意义在于构建发生的主机上不需要 Docker，因此构建可以是独立的和可移植的。

我知道这不是 Jib 问题，但我只是希望使用 Jib 的人可能会遇到类似的挑战，因此可以提供一些关于如何解决它的见解。

Answer 1

最后，使用注册表进行身份验证归结为向 Jib 提供一个简单的用户名/密码字符串对。一旦 Jib 检索到该对，Jib 只需将用户名和密码字符串按原样传递给服务器，而无需任何处理。 (顺便说一句，这种机制并非特定于 Jib；每个 Docker 注册表都以这种方式工作。)就这么简单:用户名和密码对很重要。
使用 Docker 凭证助手与通过 CLI 提供此字符串对没有什么不同。任何凭证助手都将使用“get”命令输出用户名和密码。以 Google Container Registry 为例，

$ docker-credential-gcr get <<<gcr.io
{"ServerURL":"","Username":"... this is the username ...","Secret":"... this is the password ..."}

因此，理论上您可以编写一个总是输出一些用户名/密码的哑脚本或二进制文件，将文件命名为 docker-credential-my-dumb-script , 并配置 jib.{from|to}.credHelper='my-dumb-script' .不过我不会这样做；这只是为了强调注册表身份验证只是向 Jib 提供用户名和密码对的问题。
但是，请注意，许多凭证助手会动态生成短期凭证，这些凭证很快就会过期，这比使用静态和永久凭证要安全得多。这是我们通常建议尽可能使用凭证助手的原因之一。也可能是某些云注册表只接受由其凭证助手生成的这些短期凭证。
另一个例子是 docker login .例如，使用 docker login chanseoktest.azurecr.io -u my-username -p my-password 成功登录只是导致记录 my-username和 my-password在 ~/.docker/config.json :

    "auths": {
        "chanseoktest.azurecr.io": {
            # <username>:<password> in PLAIN string in base64 encoded form
            "auth": "bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ="
        },

(如果你在 bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ= 上进行 base64-decode，它会在纯字符串中生成 my-username:my-password。)这意味着，如果你可以制作 docker pull/push在某些系统上工作，Jib 也可以工作(正如 Jib 调查 ~/.docker/config.json )。因此，向 Jib 提供凭据的另一种方法是创建一个有效的 ~/.docker/config.json。在系统上(或者您可以从成功运行 docker login 的另一个系统复制它)。这种方法，除非可以安全地完成，否则我也不会这样做。
再举一个例子，而不是愚蠢的凭证助手或 ~/.docker/config。间接，您也可以通过 jib.{from|to}.auth.{username|password} 直接将您的凭据传递给 Jib (也可以通过相应的 system properties 设置，例如 -Djib.from.auth.username=... )。只要您可以使用凭证助手，我们也不建议这样做。请注意，如果您在命令行上传递凭据，同一系统上的其他用户可以看到该命令(包括凭据)，更不用说命令可以记录或存储在 shell 历史记录中。在某些环境中，如果您将这些凭据存储在某些环境变量中并修改您的 build.gradle，则可能会降低此命令行风险。或 pom.xml阅读 jib.{from|to}.auth.{username|password}从环境变量。
有关提供用户名/密码对的完整方法列表，您可以咨询官方 FAQ .
另请注意，您认为正确的用户名和密码对可能不是您的注册表实际接受的。例如，此 AWS ECR 用户 mistakenly assumed他们可以使用“AWS ECR key 用户”(不管它是什么)作为用户名，而实际上， docker-credential-ecr-login返回 AWS作为用户名。 (并不是说您总是必须使用 AWS 作为用户名；ECR 可能(或可能没有)具有多种形式的可接受凭据。)
最后，我会与 AWS ECR 社区或您使用 Jib 的平台社区确认，如果您无法使用凭证助手。例如对于 GitHub Actions，之前我成功使用了 aws-actions/amazon-ecr-login .