<p>Here's an example of using them in a pipeline safely.  In this case, they are injected as environment variables and their value should never have to be shown unless you explicitly choose to print out the variable content for some reason or other.</p>

<p>Environment variables are generally seen as the best way to store secrets at this point and are heavily relied on by many modern deployments (e.g. often used in kubernetes apps).</p>

<p><a href="https://www.jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials" rel="noreferrer">https://www.jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials</a></p>

<pre><code>Jenkinsfile (Declarative Pipeline)
pipeline {
    agent {
        // Define agent details here
    }
    environment {
        AWS_ACCESS_KEY_ID     = credentials('jenkins-aws-secret-key-id')
        AWS_SECRET_ACCESS_KEY = credentials('jenkins-aws-secret-access-key')
    }
    stages {
        stage('Example stage 1') {
            steps {
                // 
            }
        }
        stage('Example stage 2') {
            steps {
                // 
            }
        }
    }
}
</code></pre>

<p>You can also avoid Jenkins altogether by having your pipeline/etc retrieve them from some other tool like HashiCorp Vault, AWS SSM, Azure Vault, etc.</p>

CC BY-SA 4.0
2020-04-30T01:16:59.067Z
Thanks, that is a good idea to retrive credentials from tools like AWS. I am thinking if someone wants to use the jenkins, he or she has to store their credentials in AWS, if this jenkins pipeline tools is used by a large number of people,  would that be a problem?
RTenda
CC BY-SA 4.0
2020-05-03T20:16:56.730Z
You can set things up so that most users can't touch the settings/config + credentials in Jenkins or equivalent tools.   I'd expect a service account type user to do the pipeline work and for that to be decoupled from the Jenkins user.  You may want a job (e.g. deploy to development) to be runnable by anyone but only modifiable by devops personnel, and you may want to restrict, say, the prod job to only being runnable by devops personnel who are allowed to touch prod.
John Humphreys
CC BY-SA 4.0
2020-04-30T00:50:38.733Z
2020-04-30T00:50:38.733Z
John Humphreys
<p>John's answer works just fine.  An alternative is to use the <code>withCredentials</code> block, which is built right into core Jenkins.</p>

<p><strong>Example</strong></p>

<pre class="lang-java prettyprint-override"><code>pipeline {
  agent any

  stages {
    ...
    stage('Publish') {
      steps {
        withCredentials([usernamePassword(credentialsId: 'sonar-publisher', usernameVariable: 'SONAR_USER', passwordVariable: 'SONAR_PASSWORD')]) {
          // maybe do stuff with variables, echoing them prints *****
          sh './gradlew sonar'
        }
      }
    }
  }
}
</code></pre>

<p>The only requirement in this scenario is that the credentials <code>sonar-publisher</code> exists on the Jenkins master and your job has access to them.</p>

CC BY-SA 4.0
2020-05-02T21:11:03.813Z
2020-05-02T21:11:03.813Z
brianrobt
<p>I can see credentials in Jenkins console output.  How can we encrypt them? The "Mask Passwords plugin" is considered as not safe in my case.</p>

<jenkins><credentials>
How do we encrypt credentials in Jenkins console output
RTenda
# How do we encrypt credentials in Jenkins console output

(Asked by: username_0 on 2020-04-30)

I can see credentials in Jenkins console output. How can we encrypt them? The "Mask Passwords plugin" is considered as not safe in my case.

**Tags:** jenkins, credentials


---

## 2 answers

### Answer by username_1 on 2020-04-30. Score: 5

Here's an example of using them in a pipeline safely.  In this case, they are injected as environment variables and their value should never have to be shown unless you explicitly choose to print out the variable content for some reason or other.
Environment variables are generally seen as the best way to store secrets at this point and are heavily relied on by many modern deployments (e.g. often used in kubernetes apps).
https://www.jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials
Jenkinsfile (Declarative Pipeline)
pipeline {
    agent {
        // Define agent details here
    }
    environment {
        AWS_ACCESS_KEY_ID     = credentials('jenkins-aws-secret-key-id')
        AWS_SECRET_ACCESS_KEY = credentials('jenkins-aws-secret-access-key')
    }
    stages {
        stage('Example stage 1') {
            steps {
                // 
            }
        }
        stage('Example stage 2') {
            steps {
                // 
            }
        }
    }
}

You can also avoid Jenkins altogether by having your pipeline/etc retrieve them from some other tool like HashiCorp Vault, AWS SSM, Azure Vault, etc.

> **Comments:**
> **username_0**: Thanks, that is a good idea to retrive credentials from tools like AWS. I am thinking if someone wants to use the jenkins, he or she has to store their credentials in AWS, if this jenkins pipeline tools is used by a large number of people,  would that be a problem?  
> **username_1**: You can set things up so that most users can't touch the settings/config + credentials in Jenkins or equivalent tools.   I'd expect a service account type user to do the pipeline work and for that to be decoupled from the Jenkins user.  You may want a job (e.g. deploy to development) to be runnable by anyone but only modifiable by devops personnel, and you may want to restrict, say, the prod job to only being runnable by devops personnel who are allowed to touch prod.  

---

### Answer by username_2 on 2020-05-02. Score: 0

John's answer works just fine.  An alternative is to use the withCredentials block, which is built right into core Jenkins.
Example
pipeline {
  agent any

  stages {
    ...
    stage('Publish') {
      steps {
        withCredentials([usernamePassword(credentialsId: 'sonar-publisher', usernameVariable: 'SONAR_USER', passwordVariable: 'SONAR_PASSWORD')]) {
          // maybe do stuff with variables, echoing them prints *****
          sh './gradlew sonar'
        }
      }
    }
  }
}

The only requirement in this scenario is that the credentials sonar-publisher exists on the Jenkins master and your job has access to them.


---

