Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64690

update the registry login to use --password-stdin to avoid security warning

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Trivial Trivial
    • docker-workflow-plugin
    • docker-workflow-plugin version: 1.25
      jenkins version you use: 2.263.2

      when using withRegistry (with credentials!), the following warning appers:

      WARNING! Using --password via the CLI is insecure. Use --password-stdin
      WARNING! Your password will be stored unencrypted in
      Configure a credential helper to remove this warning.
      See https://docs.docker.com/engine/reference/commandline/login/#credentials-store

      my request is to update the usage of the cli to avoid this warning.

       

      thanks.

          [JENKINS-64690] update the registry login to use --password-stdin to avoid security warning

          Allan BURDAJEWICZ added a comment - https://github.com/jenkinsci/docker-commons-plugin/blob/docker-commons-1.17/src/main/java/org/jenkinsci/plugins/docker/commons/impl/RegistryKeyMaterialFactory.java#L98-L103

          There are 2 different warnings:

          • the use of the password parameter
          • the fact that a credsStore is not used and cannot be specified with that step

          Allan BURDAJEWICZ added a comment - There are 2 different warnings: the use of the password parameter the fact that a credsStore is not used and cannot be specified with that step

          In an environment with dedicated agents (or even from the master), if they was a possibility to use a credsStore, any pipeline running in that environment would have access to the registry credentials. Unless a docker logout is executed in the end.

          Allan BURDAJEWICZ added a comment - In an environment with dedicated agents (or even from the master), if they was a possibility to use a credsStore , any pipeline running in that environment would have access to the registry credentials. Unless a docker logout is executed in the end.

          As a workaround to the withRegistry block, a very simple credentials helper like docker-credential-envvars can be used and added to the PATH. The helper only need to deal with get, as in the context of CI, if we want to avoid storing secrets. This helper uses read environment variables DOCKER_CREDS_USERNAME and DOCKER_CREDS_PASSWORD to pass authentication details to the docker CLI. It just print the following:

          {"ServerURL":"${REGISTRY_HOST}","Username":\"${DOCKER_CREDS_USERNAME}","Secret":"${DOCKER_CREDS_PASSWORD}"
          

          See https://docs.docker.com/engine/reference/commandline/login/#credentials-store for more details on this.

          Then in a pipeline, we can add the credsStore to point to the helper and then use withCredentials step to injected username / password credentials with the variable names DOCKER_CREDS_USERNAME and DOCKER_CREDS_PASSWORD.

          // Create a temporary docker config directory
          withEnv(["DOCKER_CONFIG=" + pwd(tmp:true) + "/.docker"]) {
          
            // Create a temporary Docker config file
            sh '''
              mkdir -p \${DOCKER_CONFIG}
              echo '{"credsStore":"envvars"}' > \${DOCKER_CONFIG}/config.json
            '''
            withCredentials([usernamePassword(credentialsId: 'dockerhub-ro', passwordVariable: 'DOCKER_CREDS_PASSWORD', usernameVariable: 'DOCKER_CREDS_USERNAME')]) {
          
                  // Run docker commands ....
                  [...]
          
            }
            sh "[ -d \$DOCKER_CONFIG ] && rm -rf \$DOCKER_CONFIG"
          }
          

          What looks cumbersome here could well be factored out in a global function of a shared library.

          Maybe Docker Pipeline could implement such a logic to solve that problem ?

          Allan BURDAJEWICZ added a comment - As a workaround to the withRegistry block, a very simple credentials helper like docker-credential-envvars can be used and added to the PATH . The helper only need to deal with get , as in the context of CI, if we want to avoid storing secrets. This helper uses read environment variables DOCKER_CREDS_USERNAME and DOCKER_CREDS_PASSWORD to pass authentication details to the docker CLI. It just print the following: { "ServerURL" : "${REGISTRY_HOST}" , "Username" :\ "${DOCKER_CREDS_USERNAME}" , "Secret" : "${DOCKER_CREDS_PASSWORD}" See https://docs.docker.com/engine/reference/commandline/login/#credentials-store for more details on this. Then in a pipeline, we can add the credsStore to point to the helper and then use withCredentials step to injected username / password credentials with the variable names DOCKER_CREDS_USERNAME and DOCKER_CREDS_PASSWORD . // Create a temporary docker config directory withEnv([ "DOCKER_CONFIG=" + pwd(tmp: true ) + "/.docker" ]) { // Create a temporary Docker config file sh ''' mkdir -p \${DOCKER_CONFIG} echo '{ "credsStore" : "envvars" }' > \${DOCKER_CONFIG}/config.json ''' withCredentials([usernamePassword(credentialsId: 'dockerhub-ro' , passwordVariable: 'DOCKER_CREDS_PASSWORD' , usernameVariable: 'DOCKER_CREDS_USERNAME' )]) { // Run docker commands .... [...] } sh "[ -d \$DOCKER_CONFIG ] && rm -rf \$DOCKER_CONFIG" } What looks cumbersome here could well be factored out in a global function of a shared library. Maybe Docker Pipeline could implement such a logic to solve that problem ?

            Unassigned Unassigned
            amidar Amit Dar
            Votes:
            6 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: