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

Add ability to hide output of credentials being used

    Details

    • Type: New Feature
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:
    • Released As:
      git plugin 4.4.0

      Description

      In our company we are using git plugin to checkout git repositories with centrally managed credentials.  Pipeline users should not know which credentials are being used to not give them the opportunity to use this credentials in a withCredentials block and bypass certain 4-eyes principles that are in place.  Therefore we would like to introduce the possiblity to add a global option to hide the output of credential usage in the job log.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          I'm not clear who is not allowed to see the credential identifier and how that will prevent them from obtaining the credential identifier in some other way. The credential identifier is defined as a string in the Jenkinsfile. It can be read by anyone that is authorized to read the Jenkinsfile, from the source control system, from the Jenkins job "Replay" option, and from the console log.

          In each of those cases, it is the identifier of the credential that is being read, not the value of the credential.

          Can you help me understand how it will help you to have a global option that removes the logging of credential identifiers in console output? I am hesitant to remove that output because the identifiers are quite helpful for failure diagnosis.

          Show
          markewaite Mark Waite added a comment - I'm not clear who is not allowed to see the credential identifier and how that will prevent them from obtaining the credential identifier in some other way. The credential identifier is defined as a string in the Jenkinsfile. It can be read by anyone that is authorized to read the Jenkinsfile, from the source control system, from the Jenkins job "Replay" option, and from the console log. In each of those cases, it is the identifier of the credential that is being read, not the value of the credential. Can you help me understand how it will help you to have a global option that removes the logging of credential identifiers in console output? I am hesitant to remove that output because the identifiers are quite helpful for failure diagnosis.
          Hide
          bartdevriendt Bart Devriendt added a comment -

           
          Mark Waite

          The CI/CD pipeline in our company is built as a pipeline library in groovy.  The users just have to call one method to start the pipeline with the necessary parameters.   During the pipeline credentials are being used to connect to other systems like nexus, sonar but also bitbucket.  User management is done by the team that manages the pipeline and every development team has no knowledge of these users.  Also the credentials are stored in jenkins but are not visible to the user (hidden via matrix authorization).  The credential that is stored in jenkins has write access to the Bitbucket repository.  What we don't want is that the developers somehow obtain the credentialId.  Once that would happen they would be able to call standard jenkins pipeline functions wrapped in a withCredentials call to do changes in the source directly on master or develop, and thus bypass 4 eyes principles induced by the gitflow and pull request mechanisms.  Even worse is that this way the credentials somehow could be leaked and they would have direct access to other tools via that leaked user. 

          As we have a pipeline library we know the hardcoded credential id being used in git checkout.   Currently this log line is blocking us from upgrading the plugin further than the 3.9.x version it was introduced.

          Show
          bartdevriendt Bart Devriendt added a comment -   Mark Waite The CI/CD pipeline in our company is built as a pipeline library in groovy.  The users just have to call one method to start the pipeline with the necessary parameters.   During the pipeline credentials are being used to connect to other systems like nexus, sonar but also bitbucket.  User management is done by the team that manages the pipeline and every development team has no knowledge of these users.  Also the credentials are stored in jenkins but are not visible to the user (hidden via matrix authorization).  The credential that is stored in jenkins has write access to the Bitbucket repository.  What we don't want is that the developers somehow obtain the credentialId.  Once that would happen they would be able to call standard jenkins pipeline functions wrapped in a withCredentials call to do changes in the source directly on master or develop, and thus bypass 4 eyes principles induced by the gitflow and pull request mechanisms.  Even worse is that this way the credentials somehow could be leaked and they would have direct access to other tools via that leaked user.  As we have a pipeline library we know the hardcoded credential id being used in git checkout.   Currently this log line is blocking us from upgrading the plugin further than the 3.9.x version it was introduced.

            People

            • Assignee:
              bartdevriendt Bart Devriendt
              Reporter:
              bartdevriendt Bart Devriendt
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: