Learn how to expose AWS credentials in Jenkins in one step.
A common practice when using Jenkins pipelines is that the system administrator can configure credentials in the application for dedicated use by Jenkins. Once a Jenkins manager (i.e. a Jenkins user who administers a Jenkins site) adds/configures these credentials in Jenkins, Pipeline projects can use the credentials to interact with these 3rd party applications. The Jenkins credentials functionality described on this and related pages is provided by the Credentials Binding plugin.
This works fine and is very convenient when creating Jenkins projects. They have also created a masking functionality so that it is impossible to output those credentials in the logs. When using the withCredentials( … ) { … } step of a Pipeline, credential variables' values printed (by referencing or echoing these variable values) within the step’s block are typically masked with “****” values in the console output or Jenkins log. This is done to protect the secrecy of these credentials. This prevents you from accidentally disclosing passwords and the like via the log. (Bourne shell set +x, or Windows batch @echo off, blocks secrets from being displayed in echoed commands; but build tools in debug mode might dump all environment variables to standard output/error, or poorly designed network clients might display authentication, etc.)
//Groovy example script that masks credentials
script {withCredentials([[$class: "AmazonWebServicesCredentialsBinding", credentialsId: configuration.release.staging.credentialsId]]) {
//...}
}
Of course, there is a backdoor and we can view the credentials if we like by exporting variables to a file (and not stdout)
script {withCredentials([[$class: "AmazonWebServicesCredentialsBinding", credentialsId: configuration.release.staging.credentialsId]]) { sh 'export > exported_variables.txt'}
If you check your exported_variables.txt file in your Jenkins workspace you will see all the environment variables in plain sight.
Please do not be fooled and only share those connections with trusted members. The text above is a reminder of how important is to be sure and knowledgeable on the possible security issues of our application.
The masking could of course be trivially circumvented; anyone permitted to configure a job or define Pipeline steps is assumed to be trusted to use any credentials in scope however they like. (excerpt from official documentation)