Access credentials from AWS Secrets Manager in your Jenkins jobs.
This plugin is the high-level counterpart of the AWS Secrets Manager SecretSource plugin. You can use either plugin individually, or use both of them.
CredentialsProvider
API support.Give Jenkins read access to Secrets Manager with an IAM policy.
Required permissions:
secretsmanager:GetSecretValue
secretsmanager:ListSecrets
Optional permissions:
kms:Decrypt
(if you use a customer-managed KMS key to encrypt the secret)Example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowJenkinsToGetSecretValues",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "*"
},
{
"Sid": "AllowJenkinsToListSecrets",
"Effect": "Allow",
"Action": "secretsmanager:ListSecrets"
}
]
}
The plugin uses the AWS Java SDK to communicate with Secrets Manager. If you are running Jenkins outside EC2 or EKS you may need to manually configure the SDK to authenticate with AWS. See the client configuration guide for more information.
Then, install and configure the plugin.
The plugin allows secrets from Secrets Manager to be used as Jenkins credentials.
Secrets must conform to the following rules to be usable in Jenkins:
[a-zA-Z0-9_.-]+
. If it contains other characters, you may see undefined behaviour within Jenkins (e.g. URLs containing the credential's ID may not work).Note: if you have credentials caching enabled, you must wait for the cache to reset before changes to the secrets appear.
A simple text secret.
jenkins:credentials:type
= string
AWS CLI:
aws secretsmanager create-secret --name 'newrelic-api-key' --secret-string 'abc123' --tags 'Key=jenkins:credentials:type,Value=string' --description 'Acme Corp Newrelic API key'
Declarative Pipeline:
pipeline {
agent any
environment {
NEWRELIC_API_KEY = credentials('newrelic-api-key')
}
stages {
stage('Foo') {
steps {
echo 'Hello world'
}
}
}
}
Scripted Pipeline:
node {
withCredentials([string(credentialsId: 'newrelic-api-key', variable: 'NEWRELIC_API_KEY')]) {
echo 'Hello world'
}
}
A username and password pair.
jenkins:credentials:type
= usernamePassword
jenkins:credentials:username
= usernameAWS CLI:
aws secretsmanager create-secret --name 'artifactory' --secret-string 'supersecret' --tags 'Key=jenkins:credentials:type,Value=usernamePassword' 'Key=jenkins:credentials:username,Value=joe' --description 'Acme Corp Artifactory login'
Declarative Pipeline:
pipeline {
agent any
environment {
// Creates variables ARTIFACTORY=joe:supersecret, ARTIFACTORY_USR=joe, ARTIFACTORY_PSW=supersecret
ARTIFACTORY = credentials('artifactory')
}
stages {
stage('Foo') {
steps {
echo 'Hello world'
}
}
}
}
Scripted Pipeline:
node {
withCredentials([usernamePassword(credentialsId: 'artifactory', usernameVariable: 'ARTIFACTORY_USR', passwordVariable: 'ARTIFACTORY_PSW')]) {
echo 'Hello world'
}
}
An SSH private key, with a username.
jenkins:credentials:type
= sshUserPrivateKey
jenkins:credentials:username
= usernameCommon private key formats include PKCS#1 (starts with -----BEGIN [ALGORITHM] PRIVATE KEY-----
) and PKCS#8 (starts with -----BEGIN PRIVATE KEY-----
).
Note: The passphrase field is not supported. (The SSHUserPrivateKey#getPassphrase()
implementation returns an empty string if called.) This is because any passphrase would have to be stored as a tag on the AWS secret, but tags are non-secret metadata (visible in any ListSecrets
API call), so the passphrase would offer no meaningful security benefit in this provider.
AWS CLI:
ssh-keygen -t rsa -b 4096 -C 'acme@example.com' -f id_rsa
aws secretsmanager create-secret --name 'ssh-key' --secret-string 'file://id_rsa' --tags 'Key=jenkins:credentials:type,Value=sshUserPrivateKey' 'Key=jenkins:credentials:username,Value=joe' --description 'Acme Corp SSH key'
Declarative Pipeline:
pipeline {
agent any
environment {
// Creates variables KEY=/temp/path/to/key, KEY_USR=joe
KEY = credentials('ssh-key')
}
stages {
stage('Foo') {
steps {
echo 'Hello world'
}
}
}
}
Scripted Pipeline:
node {
withCredentials([sshUserPrivateKey(credentialsId: 'ssh-key', keyFileVariable: 'KEY', usernameVariable: 'KEY_USR')]) {
echo 'Hello world'
}
}
A client certificate keystore in PKCS#12 format, encrypted with a zero-length password.
jenkins:credentials:type
= certificate
AWS CLI:
openssl pkcs12 -export -in /path/to/cert.pem -inkey /path/to/key.pem -out certificate.p12 -passout pass:
aws secretsmanager create-secret --name 'code-signing-cert' --secret-binary 'fileb://certificate.p12' --tags 'Key=jenkins:credentials:type,Value=certificate' --description 'Acme Corp code signing certificate'
Scripted Pipeline:
node {
withCredentials([certificate(credentialsId: 'code-signing-cert', keystoreVariable: 'STORE_FILE')]) {
echo 'Hello world'
}
}
A secret file with binary content and an optional filename.
jenkins:credentials:type
= file
jenkins:credentials:filename
= filename (optional)The credential ID is used as the filename by default. In the rare cases when you need to override this (for example, if the credential ID would be an invalid filename on your filesystem), you can set the jenkins:credentials:filename
tag.
AWS CLI:
echo -n $'\x01\x02\x03' > license.bin
aws secretsmanager create-secret --name 'license-key' --secret-binary 'fileb://license.bin' --tags 'Key=jenkins:credentials:type,Value=file' --description 'License key'
Declarative Pipeline:
pipeline {
agent any
environment {
LICENSE_KEY_FILE = credentials('license-key')
}
stages {
stage('Example') {
steps {
echo 'Hello world'
}
}
}
}
Scripted Pipeline:
node {
withCredentials([file(credentialsId: 'license-key', variable: 'LICENSE_KEY_FILE')]) {
echo 'Hello world'
}
}
You may need to deal with multi-field credentials or vendor-specific credential types that the plugin does not (yet) support.
In this situation you have a couple of choices:
Example: Jenkins authenticates to Secrets Manager using the primary AWS credential (from the environment). You have a job that performs a particular AWS operation in a different account, which uses a secondary AWS credential. You choose to encode the secondary AWS credential as JSON in the string credential foo
:
node {
withCredentials([string(credentialsId: 'foo', variable: 'secret')]) {
script {
def creds = readJSON text: secret
env.AWS_ACCESS_KEY_ID = creds['accessKeyId']
env.AWS_SECRET_ACCESS_KEY = creds['secretAccessKey']
env.AWS_REGION = 'us-east-1' // or whatever
}
sh "aws sts get-caller-identity" // or whatever
}
}
The plugin has a couple of optional settings to fine-tune its behavior. In most installations you do not need to change these settings. If you need to change the configuration, you can use the Web UI or CasC.
You can set plugin configuration using the Web UI.
Go to Manage Jenkins
> Configure System
> AWS Secrets Manager Credentials Provider
and change the settings.
Available settings:
You can set plugin configuration using Jenkins Configuration As Code.
Schema:
unclassified:
awsCredentialsProvider:
cache: (boolean) # optional
client: # optional
credentialsProvider: (object) # optional
endpointConfiguration: # optional
serviceEndpoint: (URL)
signingRegion: (string)
region: (string) # optional
listSecrets: # optional
filters:
- key: name
values:
- (string)
- key: tag-key
values:
- (string)
- key: tag-value
values:
- (string)
- key: description
values:
- (string)
transformations: # optional
description:
hide: {}
name: (object)
Version tags for this plugin are of the format:
<major>.<autogenerated>
For example 1.55.v0fcce24a_9501
.
The <major>
prefix is incremented to indicate breaking changes in the plugin. When this happens, please read the release notes and test the plugin extra carefully before deploying it to production. To assist users of the Jenkins Update Center we will also add an hpi.compatibleSinceVersion
annotation to the POM.
The <autogenerated>
part is created by the Jenkins automated plugin release system. This is incremented on any non-breaking (minor) change, e.g. new features, bug fixes, or dependency updates. It should normally be safe to adopt these changes straight away.
Start by cloning the project.
Note for Windows users: some of the file paths in this project may exceed the legacy Win32 path length limit. This may cause an error when cloning the project on Windows. If you see this error, enable Git's Windows longpaths support with git config --system core.longpaths true
(you might need to run Git as Administrator for this to work). Then try to clone the project again.
In Maven:
mvn clean verify
In your IDE:
mvn localizer:generate
. (This is a one-off task. You only need to re-run this if you change the translations, or if you clean the Maven target
directory. If the IDE still cannot find the translation symbols after running mvn localizer:generate
, use a one-off mvn compile
instead.)You can explore how the plugin works by running it locally with Moto (the AWS mock)...
Start Moto:
docker run -it -p 5000:5000 motoserver/moto:3.1.18
Upload some fake secrets to Moto (like these):
aws --endpoint-url http://localhost:5000 secretsmanager create-secret --name 'example-api-key' --secret-string '123456' --tags 'Key=jenkins:credentials:type,Value=string' --description 'Example API key'
Start Jenkins with the plugin:
mvn hpi:run
Edit the plugin configuration at http://localhost:8080/jenkins/configure to use Moto:
Endpoint Configuration
optionService Endpoint
to `http://localhost:5000Signing Region
to us-east-1
Save