gradle Jib：如何使用amazon-ecr-credential-helper而不安装它？

snz8szmq 于 2023-10-19 发布在其他

关注(0)|答案(2)|浏览(123)

当使用jib-gradle-plugin构建并推送到AWS ECR时，它要求我安装aws ecr credential helper，否则构建会抱怨 “系统没有docker-credential-ecr-login CLI”。
我想知道是否有一种方法可以在不安装凭据助手的情况下推送到AWS ECR，或者是否可以在repo中捆绑凭据助手的便携版本？
安装帮助程序的问题包括：
1.它需要在需要构建项目的每台机器上安装helper，因此使构建流程不像我希望的那样自动化
1.要安装aws ecr credential helper，需要安装Docker。这感觉有点讽刺，因为Jib的很大一部分要点是在构建发生的主机上不需要Docker，因此构建可以是自包含和可移植的。
我知道这不是一个Jib的问题，但我只是希望谁使用Jib可能会遇到类似的挑战，因此可以提供一些如何解决它的见解。

Gradle

来源：https://stackoverflow.com/questions/64074817/jib-how-to-use-amazon-ecr-credential-helper-without-installing-it

2条答案

按热度按时间

62o28rlo1#

最后，使用注册中心进行身份验证归结为向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成功登录只会导致在~/.docker/config.json中记录my-username和my-password：

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

(If你对bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ=进行base64解码，结果是my-username:my-password的纯字符串。）这意味着，如果你能让docker pull/push在某个系统上工作，Jib也能工作（就像Jib查看~/.docker/config.json一样）。因此，向Jib提供凭据的另一种方法是在系统上创建一个工作~/.docker/config.json（或者您可以从成功运行docker login的另一个系统复制它）。这种方法，我不会这样做，除非这可以安全地完成。
再举一个例子，除了dumb credential helper或~/.docker/config indirection之外，您还可以通过jib.{from|to}.auth.{username|password}（也可以通过相应的系统属性进行设置，例如-Djib.from.auth.username=...）直接将您的凭据传递给Jib。我们也不推荐这样做，只要你能使用凭证助手。请注意，如果您在命令行上传递凭据，同一系统上的其他用户可以看到命令（包括凭据），更不用说命令可以记录或存储在shell历史记录中。在某些环境中，如果将这些凭据存储在某些环境变量中，并修改build.gradle或pom.xml以从环境变量读取jib.{from|to}.auth.{username|password}，则可以减轻此命令行风险。
有关提供用户名/密码对的完整方法列表，请参阅官方常见问题解答。
还请注意，您认为正确的用户名和密码对可能不是您的注册表实际接受的用户名和密码对。例如，这个AWS ECR用户mistakenly assumed可以使用“AWS ECR密钥用户”（无论它是什么）作为用户名，而实际上，docker-credential-ecr-login返回AWS作为用户名。（并不是说你总是必须使用AWS作为用户名; ECR可能（或可能不）具有多种形式的可接受凭证。
最后，我会向AWS ECR社区或您使用Jib的平台社区确认，如果您无法使用凭据助手，请确定哪种凭据表单最适合用作“登录Docker”的用户名和密码对。例如，对于GitHub操作，我以前成功地使用了aws-actions/amazon-ecr-login。