如何使用amazon凭据-助手而不安装它？

Question

当使用摇臂级插件构建和推送到AWS时，它要求我安装aws ecr证书助手，否则生成时会抱怨“系统没有停靠者证书- ECR -登录CLI”。

我想知道是否有一种方法可以在不安装凭据助手的情况下推进到AWS ECR，还是可以在回购中捆绑便携版本的凭证助手？

安装助手的问题是：

1. 它要求在需要构建项目的每台机器上安装助手，从而使构建流程不像我所希望的那样自动化。
2. 要安装aws凭据助手，需要安装。这有点讽刺，因为Jib很大程度上是因为在发生构建的主机上不需要Docker，因此构建可以自我包含和可移植。

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

Answer 1

最后，使用注册表进行身份验证可以归结为向Jib提供一个简单的用户名/密码字符串对。一旦Jib检索到这对，Jib就会将用户名和密码字符串文本传递给服务器，就像没有任何处理一样。(顺便说一句，这种机制并不是针对Jib的；每个Docker注册中心都是这样工作的。)就这么简单:用户名和密码对才是最重要的。

使用Docker凭据助手与通过CLI提供此字符串对没有什么不同。任何凭据助手都会使用"get“命令输出用户名和密码。例如，对于，

$ 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'。不过，我不会这么做；这只是为了强调注册表auth只是向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="
        },

(如果您在bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ=上执行base64 64-解码，则会生成纯字符串的my-username:my-password。)这意味着，如果您可以使docker pull/push在某些系统上工作，那么Jib也会工作(正如Jib在~/.docker/config.json中所看到的那样)。因此，向Jib提供凭据的另一种方法是在系统上创建一个工作的~/.docker/config.json (或者您可以从成功运行docker login的另一个系统复制它)。这种方法，我不会做任何一个，除非这可以安全地完成。

另一个例子是，您也可以通过~/.docker/config直接将凭据传递给Jib ( jib.{from|to}.auth.{username|password}也可以通过相应的系统性质 (例如，-Djib.from.auth.username=...)来设置，而不是简单的凭据助手或系统性质间接转换)。我们也不建议这样做，只要您可以使用凭据助手。请注意，如果您在命令行上传递凭据，同一系统上的其他用户可以看到该命令(包括凭据)，更不用说命令可以记录或存储在shell历史记录中。在某些环境中，如果将这些凭据存储在某些环境变量中，并修改build.gradle或pom.xml以从环境变量读取jib.{from|to}.auth.{username|password}，则可以减轻此命令行风险。

关于提供用户名/密码对的方法的完整列表，您可以参考官方的常见问题。

另外，请注意，您认为正确的用户名和密码对可能不是您的注册表真正接受的。例如，这个AWS用户误以为表示，他们可以使用"AWS密钥用户“(不管是什么)作为用户名，而实际上，docker-credential-ecr-login将AWS作为用户名返回。(这并不是说您总是必须使用AWS作为用户名；ECR可能(或不可能)具有多种形式的可接受的凭据。)

最后，我将与AWS ECR社区或平台社区确认，如果您不能使用凭据助手，您可以使用Jib确定哪种凭据形式最好用作用户名和密码对，以“登录到Docker”。例如，对于GitHub操作，我以前成功地使用了aws-action/amazon登录。