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

Mask credentials in Build Log

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Accidents happen...

      It would be nice if the credentials introduced via this plugin were masked on the console output of a job log.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Workaround is to use the Mask Passwords plugin.

            Show
            jglick Jesse Glick added a comment - Workaround is to use the Mask Passwords plugin.
            Hide
            jot1109 Jochen Hinrichsen added a comment -

            Jesse, i'm looking for just this particular workaround until this issue is resolved. My jobs are not using credentials as parameters, but the credentialsBinding DSL/ "Build environment -> Bindings" setup. My combination of Jenkins Credentials Binding Plugin and Mask Passwords plugin (LTS/ latest/ latest) shows credential passwords. Could you please elaborate on what you did to mask those?

            Any insights greatly appreciated.

            Show
            jot1109 Jochen Hinrichsen added a comment - Jesse, i'm looking for just this particular workaround until this issue is resolved. My jobs are not using credentials as parameters, but the credentialsBinding DSL/ "Build environment -> Bindings" setup. My combination of Jenkins Credentials Binding Plugin and Mask Passwords plugin (LTS/ latest/ latest) shows credential passwords. Could you please elaborate on what you did to mask those? Any insights greatly appreciated.
            Hide
            arumugam Arumugam Subramanian added a comment -

            Having same issue. Android gradle commandline doesnt work with mask password or envinject plugin to pass password as build parameter. Any idea would really helpful.

            Show
            arumugam Arumugam Subramanian added a comment - Having same issue. Android gradle commandline doesnt work with mask password or envinject plugin to pass password as build parameter. Any idea would really helpful.
            Hide
            adommasch Alex Dommasch added a comment -

            I also couldn't figure out any way to make the "Mask Passwords Plugin" work with the "Credentials Binding Plugin", so if anyone has advice on the supposed workaround I would really like to hear it! (I, too, am passing a secret on the gradle command line - in my case using "-D", since this needs to work smoothly both on Jenkins and in a local IDE, and referencing env vars directly in the gradle script is troublesome locally.)

            Of course, even better will be when a workaround isn't needed anymore - looking forward to the "Credentials Binding Plugin" being able to do some kind of password masking in the output.

            Show
            adommasch Alex Dommasch added a comment - I also couldn't figure out any way to make the "Mask Passwords Plugin" work with the "Credentials Binding Plugin", so if anyone has advice on the supposed workaround I would really like to hear it! (I, too, am passing a secret on the gradle command line - in my case using "-D", since this needs to work smoothly both on Jenkins and in a local IDE, and referencing env vars directly in the gradle script is troublesome locally.) Of course, even better will be when a workaround isn't needed anymore - looking forward to the "Credentials Binding Plugin" being able to do some kind of password masking in the output.
            Hide
            idstein Paul Idstein added a comment -

            There are currently 2 ways to mask passwords.

            A) Mark a build variable as sensitive. This works for any Maven or Ant build as they will mask the sensitive variables when used. The Core Jenkins team needs to extend this to all command line tools. Yet the will have no other choice than to re-use the mechanism as implemented by the "Mask password plugin" as these build steps have no mean of sensitive variables (expect something like echo off).
            B) Use a custom log formatter to mask any occurrence of a given variables content. This will work is currently implemented by the "Mask passwords plugin" and "Credentials binding plugin" (yet only for the pipeline step).

            Variant B will fail under some circumstances to match all secretes in the output log. Its internal implementation will create as soon as it knows all secrete variables values a large regex pattern such as "secret|mysecret|anothersecret".

            As you may guess this will fail to match all secrets in the log correctly as "secret" will always match also "mysecret" and "anothersecret" before even checked against those ones.
            The pull request will fix this by ordering the sensitive variables values by there length and constructing a regex pattern, that will try to match the most complex secrets first, e.g. "anothersecret|mysecret|secret".

            In addition to that, anything that closely matches the sensitive variable content will be masked. Such as path that may contain by mistake the secret value, e.g. /some/path/to/secret/files/on/disk is masked as /some/path/to/****/files/on/disk. Anyone with a decent amount or read access to the workspace may figure out what has been masked. To circumvent this issue, you should use passwords that have a solid random [a-zA-Z0-9!\.«@.] (at least on number, lower and upper character and special characters).

            Show
            idstein Paul Idstein added a comment - There are currently 2 ways to mask passwords. A) Mark a build variable as sensitive. This works for any Maven or Ant build as they will mask the sensitive variables when used. The Core Jenkins team needs to extend this to all command line tools. Yet the will have no other choice than to re-use the mechanism as implemented by the "Mask password plugin" as these build steps have no mean of sensitive variables (expect something like echo off). B) Use a custom log formatter to mask any occurrence of a given variables content. This will work is currently implemented by the "Mask passwords plugin" and "Credentials binding plugin" (yet only for the pipeline step). Variant B will fail under some circumstances to match all secretes in the output log. Its internal implementation will create as soon as it knows all secrete variables values a large regex pattern such as "secret|mysecret|anothersecret". As you may guess this will fail to match all secrets in the log correctly as "secret" will always match also "mysecret" and "anothersecret" before even checked against those ones. The pull request will fix this by ordering the sensitive variables values by there length and constructing a regex pattern, that will try to match the most complex secrets first, e.g. "anothersecret|mysecret|secret". In addition to that, anything that closely matches the sensitive variable content will be masked. Such as path that may contain by mistake the secret value, e.g. /some/path/to/secret/files/on/disk is masked as /some/path/to/****/files/on/disk. Anyone with a decent amount or read access to the workspace may figure out what has been masked. To circumvent this issue, you should use passwords that have a solid random [a-zA-Z0-9!\.«@.] (at least on number, lower and upper character and special characters).
            Hide
            harrygg Harry G. added a comment -

            This sounds like good hints to implement a fix.

            But does anyone have a workaround (for shell/batch build steps) - with use of Credentials plugin?

            Without Credentials plugin, possible Workarounds are env inject plugin or mask password plugin, which mask correctly.
            But they use directly entered single passwords in the job config (mask password addtionally global passwords).
            Also both are not useable for templates, as templates only have Credentials parameter type.

            Show
            harrygg Harry G. added a comment - This sounds like good hints to implement a fix. But does anyone have a workaround (for shell/batch build steps) - with use of Credentials plugin? Without Credentials plugin, possible Workarounds are env inject plugin or mask password plugin, which mask correctly. But they use directly entered single passwords in the job config (mask password addtionally global passwords). Also both are not useable for templates, as templates only have Credentials parameter type.
            Hide
            harrygg Harry G. added a comment - - edited

            After this discussion
            https://groups.google.com/forum/#!topic/jenkinsci-users/GgX3RSckVlI
            I found out that this issue occurs in freestyle job only and not in pipeline.

            Test cases:
            1. Freestyle job -> both username and password visible in the log
            Restrict to label "OS:Linux"
            (X) Use secret text(s) or file(s) -> Username and password (separated) -> Env vars USERNAME and PASSWORD
            Add build step shell
            env
            echo $USERNAME $PASSWORD

            2. Pipeline -> both username and password masked as **** in the log, but successfully injected (verified in test.txt)
            node ('OS:Linux') {
            withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'bccee5af-b682-407b-9171-43e38723460a', passwordVariable: 'PASSWORD', usernameVariable: 'USERNAME']])

            { sh 'env' sh 'echo $USERNAME $PASSWORD' sh 'echo $USERNAME $PASSWORD > test.txt' archive 'test.txt' }

            }

            Show
            harrygg Harry G. added a comment - - edited After this discussion https://groups.google.com/forum/#!topic/jenkinsci-users/GgX3RSckVlI I found out that this issue occurs in freestyle job only and not in pipeline. Test cases: 1. Freestyle job -> both username and password visible in the log Restrict to label "OS:Linux" (X) Use secret text(s) or file(s) -> Username and password (separated) -> Env vars USERNAME and PASSWORD Add build step shell env echo $USERNAME $PASSWORD 2. Pipeline -> both username and password masked as **** in the log, but successfully injected (verified in test.txt) node ('OS:Linux') { withCredentials([ [$class: 'UsernamePasswordMultiBinding', credentialsId: 'bccee5af-b682-407b-9171-43e38723460a', passwordVariable: 'PASSWORD', usernameVariable: 'USERNAME'] ]) { sh 'env' sh 'echo $USERNAME $PASSWORD' sh 'echo $USERNAME $PASSWORD > test.txt' archive 'test.txt' } }
            Hide
            brianeray Brian Ray added a comment -

            Apologies as this may be a mild hijack of this issue, but I want to find out whether this edge masking case warrants a JIRA and whether one already exists (don't think so, I just scanned all with component = credentials-binding-plugin).

            Minimal reproduction script is:

            node() {
              withCredentials( [] ) {
                  echo 'Test of the credentials binding decorator'
              }
            }
            

            So, passing an empty list of credentials--my concrete use case constructs the list based on upstream factors; some of the times there are no credentials to resolve so the list is empty. The relevant part of the log then winds up like this:

            [Pipeline] Bind credentials to variables : Start
            [Pipeline] withCredentials {
            [Pipeline] echo
            ****T****e****s****t**** ****o****f**** ****t****h****e**** ****c****r****e****d****e****n****t****i****a****l****s**** ****b****i****n****d****i****n****g**** ****d****e****c****o****r****a****t****o****r****
            ****
            ****[Pipeline] } //withCredentials
            [Pipeline] Bind credentials to variables : End
            
            

            I believe it's because BindingStep.Filter::Filter builds a zero-length pattern in this scenario, which matches like crazy.

            Is this a bug?

            Show
            brianeray Brian Ray added a comment - Apologies as this may be a mild hijack of this issue, but I want to find out whether this edge masking case warrants a JIRA and whether one already exists (don't think so, I just scanned all with component = credentials-binding-plugin). Minimal reproduction script is: node() { withCredentials( [] ) { echo 'Test of the credentials binding decorator' } } So, passing an empty list of credentials--my concrete use case constructs the list based on upstream factors; some of the times there are no credentials to resolve so the list is empty. The relevant part of the log then winds up like this: [Pipeline] Bind credentials to variables : Start [Pipeline] withCredentials { [Pipeline] echo ****T****e****s****t**** ****o****f**** ****t****h****e**** ****c****r****e****d****e****n****t****i****a****l****s**** ****b****i****n****d****i****n****g**** ****d****e****c****o****r****a****t****o****r**** **** ****[Pipeline] } //withCredentials [Pipeline] Bind credentials to variables : End I believe it's because BindingStep.Filter::Filter builds a zero-length pattern in this scenario, which matches like crazy. Is this a bug?
            Hide
            jglick Jesse Glick added a comment -

            Brian Ray sounds like an unrelated bug which should be filed separately.

            Show
            jglick Jesse Glick added a comment - Brian Ray sounds like an unrelated bug which should be filed separately.
            Hide
            brianeray Brian Ray added a comment -

            Jesse Glick, thanks. It's JENKINS-34823. Entered as a Priority: minor.

            Show
            brianeray Brian Ray added a comment - Jesse Glick , thanks. It's JENKINS-34823 . Entered as a Priority: minor.
            Hide
            dtranter Dan Tranter added a comment -

            Just curious if there was any recent movement or potential fix for this on credential-binding for FreeStyle jobs

            Show
            dtranter Dan Tranter added a comment - Just curious if there was any recent movement or potential fix for this on credential-binding for FreeStyle jobs
            Hide
            psgrove Paul Grove added a comment -

            As this article states this is "current best-practices" maybe then some effort should be made to kill the bugs of the credential bind plugin that makes the best practice insecure. This ticket has been open for 2 years. Due to this bug the plugin is disabled in our company, leading to yet more hack workarounds that sap our time. Please fix!

            Show
            psgrove Paul Grove added a comment - As this article states this is "current best-practices" maybe then some effort should be made to kill the bugs of the credential bind plugin that makes the best practice insecure. This ticket has been open for 2 years. Due to this bug the plugin is disabled in our company, leading to yet more hack workarounds that sap our time. Please fix!
            Hide
            abayer Andrew Bayer added a comment -

            One more attempt at a PR up for review - https://github.com/jenkinsci/credentials-binding-plugin/pull/28

            Show
            abayer Andrew Bayer added a comment - One more attempt at a PR up for review - https://github.com/jenkinsci/credentials-binding-plugin/pull/28
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            src/main/java/org/jenkinsci/plugins/credentialsbinding/MultiBinding.java
            src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java
            src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapper.java
            http://jenkins-ci.org/commit/credentials-binding-plugin/a47f4b8529fd216c3c797566aa969191834abd7a
            Log:
            JENKINS-24805 First work on masking secrets in freestyle logs.

            This still needs tests - I just want to make sure the approach is right.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/org/jenkinsci/plugins/credentialsbinding/MultiBinding.java src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapper.java http://jenkins-ci.org/commit/credentials-binding-plugin/a47f4b8529fd216c3c797566aa969191834abd7a Log: JENKINS-24805 First work on masking secrets in freestyle logs. This still needs tests - I just want to make sure the approach is right.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/java/org/jenkinsci/plugins/credentialsbinding/MultiBinding.java
            src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java
            src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapper.java
            src/test/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapperTest.java
            http://jenkins-ci.org/commit/credentials-binding-plugin/d2bcf977eb334ee93774c94d8db1007afc5cad41
            Log:
            Merge pull request #28 from abayer/jenkins-24805

            JENKINS-24805 Start masking secrets in freestyle logs.

            Compare: https://github.com/jenkinsci/credentials-binding-plugin/compare/686a29f57bf7...d2bcf977eb33

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/credentialsbinding/MultiBinding.java src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapper.java src/test/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapperTest.java http://jenkins-ci.org/commit/credentials-binding-plugin/d2bcf977eb334ee93774c94d8db1007afc5cad41 Log: Merge pull request #28 from abayer/jenkins-24805 JENKINS-24805 Start masking secrets in freestyle logs. Compare: https://github.com/jenkinsci/credentials-binding-plugin/compare/686a29f57bf7...d2bcf977eb33
            Hide
            akostadinov akostadinov added a comment -

            Thanks a lot for implementing this! Which version of plug-in would have these changes?

            Show
            akostadinov akostadinov added a comment - Thanks a lot for implementing this! Which version of plug-in would have these changes?
            Hide
            abayer Andrew Bayer added a comment -

            It'll be in the next release, 1.10.

            Show
            abayer Andrew Bayer added a comment - It'll be in the next release, 1.10.
            Hide
            jglick Jesse Glick added a comment -

            …which is released.

            Show
            jglick Jesse Glick added a comment - …which is released.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                walterk82 Walter Kacynski
              • Votes:
                13 Vote for this issue
                Watchers:
                22 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: