最后，使用注册表进行身份验证都归结为向 Jib 提供一个简单的用户名/密码字符串对。一旦 Jib 检索到该对，Jib 就将用户名和密码字符串按原样传递到服务器，而不进行任何处理。 （顺便说一句，这种机制并不是 Jib 特有的；每个 Docker 注册表都以这种方式工作。）就是这么简单：用户名和密码对才是最重要的。
使用 Docker 凭证帮助程序与通过 CLI 提供此字符串对没有什么不同。任何凭证助手都会使用“get”命令输出用户名和密码。例如，使用 Google 容器注册表，
$ 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 and my-password in ~/.docker/config.json:
"auths": {
"chanseoktest.azurecr.io": {
# <username>:<password> in PLAIN string in base64 encoded form
"auth": "bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ="
},
（如果您对bXktdXNlcm5hbWU6bXktcGFzc3dvcmQ=，结果是my-username:my-password以纯字符串形式。）这意味着，如果你可以使docker pull/push在某些系统上工作，Jib 也可以工作（正如 Jib 所研究的那样）~/.docker/config.json）。因此，向 Jib 提供凭据的另一种方法是创建一个工作~/.docker/config.json在系统上（或者您可以从成功运行的另一个系统复制它docker login）。这种方法，除非可以安全地完成，否则我也不会这样做。
再举一个例子，而不是愚蠢的凭证助手或~/.docker/config间接，您还可以通过以下方式直接将您的凭据传递给 Jibjib.{from|to}.auth.{username|password}（也可以通过相应的系统属性与，例如，-Djib.from.auth.username=...）。只要您可以使用凭据助手，我们也不推荐这样做。请注意，如果您在命令行上传递凭据，同一系统上的其他用户可以看到该命令（包括凭据），更不用说命令可以记录或存储在 shell 历史记录中。在某些环境中，如果您将这些凭据存储在某些环境变量中并修改您的build.gradle or pom.xml读书jib.{from|to}.auth.{username|password}来自环境变量。
有关提供用户名/密码对的完整方法列表，您可以咨询官方FAQ.
另请注意，您认为正确的用户名和密码对可能不是您的注册表实际接受的用户名和密码对。例如，此 AWS ECR 用户错误地假设他们可以使用“AWS ECR 密钥用户”（无论它是什么）作为用户名，而实际上，docker-credential-ecr-login回AWS作为用户名。 （并不是说你总是必须使用AWS作为用户名； ECR 可能（也可能没有）具有多种形式的可接受的凭证。）
最后，我将与 AWS ECR 社区或您使用 Jib 的平台社区进行确认，以找出最适合用作“登录 Docker”的用户名和密码对（如果您无法使用凭证助手。例如，对于 GitHub Actions，之前我成功使用过AWS 操作/亚马逊 ECR 登录.
