Credentials plugin for secrets in Jenkins - Commands & Configuration

Introduction

Managing passwords and secret keys safely is important to keep your projects secure. The Jenkins Credentials plugin helps you store and use these secrets without exposing them in your code or logs.

When you need to store a password for a database connection securely in Jenkins.

When your build process requires an API token that should not be visible in the pipeline code.

When you want to share SSH keys safely between Jenkins jobs without exposing them.

When you want to avoid hardcoding sensitive information in your Jenkinsfiles or scripts.

When multiple team members need access to the same secret but you want to control who can see or edit it.

Commands

This command adds a new secret credential to Jenkins using an XML file. It helps automate adding secrets without using the web interface.

Terminal

java -jar jenkins-cli.jar -s http://localhost:8080 create-credentials-by-xml system::system::jenkins _ < credentials.xml

Expected Output

Created credentials with ID 'my-secret-id'

→

-s - Specifies the Jenkins server URL

This command lists all credentials stored in Jenkins for the system scope, so you can verify your secret was added.

Terminal

java -jar jenkins-cli.jar -s http://localhost:8080 list-credentials system::system::jenkins _

Expected Output

ID: my-secret-id

Description: My secret password

→

-s - Specifies the Jenkins server URL

This command runs a Groovy script on Jenkins that prints the secret stored in the environment variable MY_SECRET, showing how to access credentials in a script.

Terminal

echo 'echo $MY_SECRET' | java -jar jenkins-cli.jar -s http://localhost:8080 groovy =

Expected Output

mySuperSecretValue

→

-s - Specifies the Jenkins server URL

Key Concept

If you remember nothing else from this pattern, remember: store secrets securely in Jenkins Credentials and never hardcode them in your pipeline code.

Common Mistakes

Hardcoding passwords or tokens directly in Jenkinsfiles or scripts.

This exposes secrets in logs and source control, risking security breaches.

Use the Credentials plugin to store secrets and reference them securely in your pipeline.

Not setting correct permissions on credentials, allowing all users to see sensitive data.

Anyone with access can view or misuse the secrets, breaking security policies.

Set proper access controls and restrict who can view or modify credentials.

Using plain text files to import credentials without encryption.

Secrets can be exposed during transfer or storage if not encrypted.

Use Jenkins CLI with secure connections and encrypted storage for credentials.

Summary

Use Jenkins Credentials plugin to store secrets like passwords and tokens securely.

Add credentials via Jenkins CLI or web interface to avoid exposing secrets in code.

Access stored credentials in pipelines or scripts without hardcoding sensitive data.

Practice

1. What is the main purpose of the Jenkins Credentials plugin?

easy

A. To monitor Jenkins server performance

B. To create Jenkins jobs automatically

C. To securely store and manage secrets like passwords and tokens

D. To generate build reports

Solution

1. Step 1: Understand the role of the Credentials plugin

   The plugin is designed to keep sensitive information safe within Jenkins.

2. Step 2: Identify the correct purpose

   It stores secrets like passwords, tokens, and keys securely, preventing exposure in code or logs.

3. Final Answer:

   To securely store and manage secrets like passwords and tokens -> Option C

4. Quick Check:

   Credentials plugin = secure secret storage [OK]

Hint: Remember: Credentials plugin = safe secret storage [OK]

Common Mistakes:

• Confusing credentials with job creation
• Thinking it monitors performance
• Assuming it generates reports

2. Which syntax correctly references a stored secret using the Credentials plugin in a Jenkins pipeline script?

easy

A. withCredentials([string(credentialsId: 'my-secret', variable: 'PASSWORD')]) { ... }

B. useCredentials('my-secret') { ... }

C. credentials('my-secret') { ... }

D. getSecret('my-secret') { ... }

Solution

1. Step 1: Recall the correct pipeline syntax

   The Jenkins pipeline uses withCredentials to bind secrets to environment variables.

2. Step 2: Match the correct syntax

   The correct form is withCredentials([string(credentialsId: 'id', variable: 'VAR')]) { ... }.

3. Final Answer:

   withCredentials([string(credentialsId: 'my-secret', variable: 'PASSWORD')]) { ... } -> Option A

4. Quick Check:

   Use withCredentials + credentialsId [OK]

Hint: Use withCredentials and credentialsId to access secrets [OK]

Common Mistakes:

• Using non-existent functions like useCredentials
• Omitting the variable name binding
• Incorrect function names like getSecret

3. Given this Jenkins pipeline snippet:

pipeline {
  agent any
  stages {
    stage('Use Secret') {
      steps {
        withCredentials([string(credentialsId: 'api-key', variable: 'API_KEY')]) {
          sh 'echo $API_KEY'
        }
      }
    }
  }
}

What will be the output of the sh 'echo $API_KEY' command during the build?

medium

A. The actual secret value stored under 'api-key'

B. The literal string '$API_KEY'

C. An error saying variable not found

D. Empty output with no value

Solution

1. Step 1: Understand withCredentials behavior

   The withCredentials block injects the secret as an environment variable named API_KEY.

2. Step 2: Analyze the shell command

   The shell command echo $API_KEY prints the value of the environment variable, which is the secret.

3. Final Answer:

   The actual secret value stored under 'api-key' -> Option A

4. Quick Check:

   withCredentials injects secret = actual secret output [OK]

Hint: withCredentials sets env var; echo prints secret value [OK]

Common Mistakes:

• Expecting literal variable name output
• Thinking it causes an error
• Assuming variable is empty

4. You wrote this Jenkins pipeline snippet but get an error:

withCredentials([string(credentialsId: 'my-secret')]) {
  sh 'echo $SECRET'
}

What is the likely cause of the error?

medium

A. Using string instead of usernamePassword type

B. Missing variable name binding in withCredentials block

C. Incorrect credentialsId value

D. Echo command syntax is wrong

Solution

1. Step 1: Check withCredentials syntax

   The string step requires both credentialsId and variable keys.

2. Step 2: Identify missing part

   The snippet lacks variable: 'SECRET', so the environment variable is not set.

3. Final Answer:

   Missing variable name binding in withCredentials block -> Option B

4. Quick Check:

   Always specify variable name with credentialsId [OK]

Hint: Always bind variable name with credentialsId [OK]

Common Mistakes:

• Forgetting variable binding
• Assuming credentialsId alone works
• Blaming shell command syntax

5. You want to use a secret stored as a username and password in Jenkins Credentials plugin inside a pipeline. Which is the correct way to access both values securely?

hard

A. withCredentials([certificate(credentialsId: 'cred-id', variable: 'CERT')]) { sh 'echo $CERT' }

B. withCredentials([string(credentialsId: 'cred-id', variable: 'USER')]) { sh 'echo $USER' }

C. withCredentials([file(credentialsId: 'cred-id', variable: 'FILE')]) { sh 'cat $FILE' }

D. withCredentials([usernamePassword(credentialsId: 'cred-id', usernameVariable: 'USER', passwordVariable: 'PASS')]) { sh 'echo $USER $PASS' }

Solution

1. Step 1: Identify credential type for username and password

   Use usernamePassword type to access both username and password.

2. Step 2: Use correct variable bindings

   Bind username to USER and password to PASS variables inside withCredentials.

3. Final Answer:

   withCredentials([usernamePassword(credentialsId: 'cred-id', usernameVariable: 'USER', passwordVariable: 'PASS')]) { sh 'echo $USER $PASS' } -> Option D

4. Quick Check:

   usernamePassword + two variables = correct access [OK]

Hint: Use usernamePassword type for user and pass secrets [OK]

Common Mistakes:

• Using string type for username/password secrets
• Confusing file or certificate types
• Not binding both username and password variables