How to use a username and password stored in AWS Secrets Manager in my Jenkins job?

Question

I have a Jenkins Pipeline that runs Cypress Tests on a Docker Container. The tests need a username and password to login to the web application. I have saved the username and password in AWS Secrets Manager. I can do that when I execute a shell command as a build step

USERNAME=$(aws secretsmanager get-secret-value --region us-east-2 --secret-id myID | jq -r .SecretString | jq -r .username)
PASSWORD=$(aws secretsmanager get-secret-value --region us-east-2 --secret-id myID | jq -r .SecretString | jq -r .password)

docker run -e NO_COLOR=1 -v "$PWD":/workdir -w /workdir --entrypoint=cypress 1.dkr.ecr.us-east-2.amazonaws.com/cypress/included:3.8.3 run  --env username="$USERNAME",password="$PASSWORD" 

However, I want to create a Jenkins Pipeline job and do this from JenkinsFile. How can I read the username and password from AWS Secrets Manager in the Jenkinsfile?

Answer 1

You have the sh step.

steps {
  script {
    username = sh (script: "aws secretsmanager get-secret-value --region us-east-2 --secret-id myID | jq -r .SecretString | jq -r .username", returnStdout: true)
    password = sh (script: "aws secretsmanager get-secret-value --region us-east-2 --secret-id myID | jq -r .SecretString | jq -r .password", returnStdout: true)
  }
}

Answer 2

You can also use the Jenkins credentials provider API to achieve this.

There are multiple advantages to using the credentials provider API rather than a script step:

• The credentials in your Jenkins pipeline script (the 'what') are decoupled from the logic that looks them up (the 'how'), keeping your scripts more clean and portable.
• You can have multiple credentials providers loaded if you need to read credentials from multiple locations.
• Credentials providers efficiently cache secret metadata, while ensuring that secret values stay out of memory until the moment they're needed.
• Jenkins automatically masks credential values that are printed in the build log, so it's harder to leak the values by accident.
• The Jenkins credentials UI and job builder UI show you which credentials are available, making it easier to craft job scripts.

It is true that there is some upfront complexity in setting up a credentials provider compared to a script step. However if you are using credentials in more than 1 or 2 scripts, or any of your credentials would have non-trivial consequences if they were mismanaged or leaked (eg Artifactory upload keys), I definitely think it's worth taking that cost now, in return for much easier credentials management and maintenance later.

See more info in the Jenkins documentation .

Example

If you want to use the credentials provider API with secrets that you've stored in Secrets Manager, you would use the AWS Secrets Manager Credentials Provider plugin. (Disclaimer: I am the maintainer of that plugin.)

First we install the AWS Secrets Manager Credentials Provider plugin on Jenkins, and grant Jenkins IAM access to Secrets Manager.

Then we upload a Jenkins username with password credential called 'artifactory' to Secrets Manager, which contains the username 'joe' (non-sensitive information) and the password 'supersecret' (sensitive information).

aws secretsmanager create-secret \
  --name 'artifactory' \
  --secret-string 'supersecret' \
  --description 'Acme Corp Artifactory user' \
  --tags 'Key=jenkins:credentials:username,Value=joe' 'Key=jenkins:credentials:type,Value=usernamePassword'

Then we bind the 'artifactory' credential in our Jenkinsfile.

pipeline {
    agent any
    environment {
        ARTIFACTORY = credentials('artifactory')
    }
    stages {
        stage('Foo') {
            steps {
                // Three environment variables are now available to use however you want:
                //
                // ARTIFACTORY=joe:supersecret
                // ARTIFACTORY_USR=joe
                // ARTIFACTORY_PSW=supersecret
                
                sh './deploy'
            }
        }
    }
}