Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-04-30T01:16:59.067Z
Answers: 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?
Answers: RTenda
Answers: CC BY-SA 4.0
Answers: 2020-05-03T20:16:56.730Z
Answers: 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.
Answers: John Humphreys
Answers: CC BY-SA 4.0
Answers: 2020-04-30T00:50:38.733Z
Answers: 2020-04-30T00:50:38.733Z
Answers: John Humphreys
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-05-02T21:11:03.813Z
Answers: 2020-05-02T21:11:03.813Z
Answers: brianrobt
Body: <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>
  
Tags: <jenkins><credentials>
Title: How do we encrypt credentials in Jenkins console output
UserDisplayName: RTenda
ThreadText: # 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
  
  username_1's answer works just fine. An alternative is to use the `withCredentials` block, which is built right into core Jenkins.
  
  **Example**
  
  ```java
  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.
  
  
  ---
  
  