Jenkins Credentials and Secrets Management: Stop Hardcoding, Start Sleeping at Night

I've seen a startup's entire AWS account get pwned because someone committed a Jenkinsfile with a hardcoded AWS secret key. The repo was public. Within 20 minutes, crypto miners were spinning up instances. That's the cost of treating secrets like config. Jenkins credentials management isn't a 'nice to have' — it's the difference between a production incident and a headline. This article gives you the exact patterns to store, inject, and rotate secrets in Jenkins without the bullshit. By the end, you'll know how to use the Credentials plugin, avoid the classic 'secret in logs' trap, and set up automatic rotation that doesn't require a human to remember.

Why You Can't Just Use Environment Variables

The first thing every junior does is set environment variables in Jenkins job config. That's fine for non-sensitive config like log levels. But environment variables are visible in the Jenkins UI, in job logs if you echo them, and in the process list on the agent. I've debugged a production issue where a developer printed env.DATABASE_URL in a pipeline step and the entire database connection string — including password — ended up in the build logs. The logs were stored in S3 with public read access. Don't be that person. Use the Credentials plugin. It encrypts secrets at rest (AES-256) and masks them in logs. The only way to expose them is to explicitly echo them — which you shouldn't do.

// io.thecodeforge — DevOps tutorial

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                withCredentials([
                    string(credentialsId: 'db-password', variable: 'DB_PASSWORD'),
                    usernamePassword(credentialsId: 'aws-creds', usernameVariable: 'AWS_ACCESS_KEY', passwordVariable: 'AWS_SECRET_KEY')
                ]) {
                    sh '''
                        # Secrets are available as env vars, but Jenkins masks them in logs
                        echo "Deploying with DB password: $DB_PASSWORD"  # Outputs: ****
                        aws ec2 describe-instances --region us-east-1
                    '''
                }
            }
        }
    }
}

The Right Way: Credentials Binding Plugin

The Credentials Binding plugin is your best friend. It lets you bind a credential to a variable that's only available inside the withCredentials block. Outside that block, the variable is undefined. This scoping prevents accidental leaks. The plugin supports multiple credential types: secret text, username+password, SSH keys, certificates, and more. For each type, you specify a credentialsId (a unique identifier you create in Jenkins) and a variable name. Inside the block, you can use the variable in shell scripts, environment variables, or as arguments to tools. The plugin also handles masking: if the secret value appears in the console output, Jenkins replaces it with ****. But don't rely on masking alone — it's not perfect. I've seen cases where a secret was split across multiple lines and leaked partially.

// io.thecodeforge — DevOps tutorial

pipeline {
    agent any
    environment {
        // Non-sensitive config can stay here
        DEPLOY_ENV = 'production'
    }
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build and Push') {
            steps {
                withCredentials([
                    string(credentialsId: 'dockerhub-token', variable: 'DOCKER_PASSWORD'),
                    usernamePassword(credentialsId: 'dockerhub-creds', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')
                ]) {
                    sh '''
                        echo "$DOCKER_PASSWORD" | docker login --username "$DOCKER_USER" --password-stdin
                        docker build -t myapp:latest .
                        docker push myapp:latest
                    '''
                }
            }
        }
    }
}

SSH Keys and Certificates: The Tricky Ones

SSH keys and certificates are the most common source of credential mismanagement. People store them as secret text, but SSH keys have a specific format and need to be written to a file before use. The sshPrivateKey credential type handles this: it writes the key to a temporary file, sets the SSH_AUTH_SOCK environment variable, and cleans up after the block. Never write the key yourself — you'll forget to delete the file. I've seen a build agent accumulate hundreds of SSH key files over months because a pipeline used sh 'echo "$SSH_KEY" > /tmp/key' and never cleaned up. The Credentials Binding plugin does it right.

// io.thecodeforge — DevOps tutorial

pipeline {
    agent any
    stages {
        stage('Deploy via SSH') {
            steps {
                withCredentials([
                    sshPrivateKey(
                        credentialsId: 'deploy-key',
                        keyFileVariable: 'SSH_KEY_FILE',
                        passphraseVariable: 'SSH_PASSPHRASE'
                    )
                ]) {
                    sh '''
                        ssh -i "$SSH_KEY_FILE" -o StrictHostKeyChecking=no deploy@server "systemctl restart myapp"
                    '''
                }
            }
        }
    }
}

Secret Rotation: Automate or Die

Static secrets are a liability. If a credential leaks, you need to rotate it fast. Jenkins doesn't have built-in rotation, but you can automate it with the Jenkins API and a cron job. The pattern: generate a new secret, update the credential in Jenkins via the API, then invalidate the old one. This works for database passwords, API tokens, and SSH keys. I've set this up for a client where every 30 days, a Lambda function generates a new database password, updates the Jenkins credential, and triggers a pipeline that updates the database. No human involved. The key is to use the Credentials plugin's REST API: POST /credentials/store/system/domain/_/credential with the new value. You can do this from any script.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Rotate a Jenkins credential via API
# Usage: ./rotate-credential.sh <credential-id> <new-secret>

CREDENTIAL_ID=$1
NEW_SECRET=$2
JENKINS_URL="https://jenkins.example.com"
API_USER="admin"
API_TOKEN="your-api-token"

# Generate the JSON payload for a secret text credential
PAYLOAD=$(cat <<EOF
{
  "": "0",
  "credentials": {
    "scope": "GLOBAL",
    "id": "$CREDENTIAL_ID",
    "secret": "$NEW_SECRET",
    "description": "Rotated on $(date)",
    "stapler-class": "com.cloudbees.plugins.credentials.impl.StringCredentialsImpl"
  }
}
EOF
)

# Update the credential (create if not exists, update if exists)
curl -X POST "$JENKINS_URL/credentials/store/system/domain/_/createCredentials" \
    --user "$API_USER:$API_TOKEN" \
    --data-urlencode "json=$PAYLOAD" \
    -H "Content-Type: application/x-www-form-urlencoded"

echo "Credential $CREDENTIAL_ID rotated."

When Not to Use Jenkins Credentials

Jenkins credentials are great for secrets used by Jenkins itself. But if you have a microservice that needs secrets at runtime, don't store them in Jenkins — use a dedicated secrets manager like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Jenkins credentials are static and tied to the CI/CD pipeline. For runtime secrets, your app should fetch them from a vault at startup. Also, if you have hundreds of secrets, managing them in Jenkins UI becomes a nightmare. Use the Jenkins Configuration as Code plugin to define credentials in YAML, or use an external tool to sync secrets from a vault to Jenkins. I've seen teams with 500+ credentials in Jenkins — it's unmanageable. Automate the sync.

# io.thecodeforge — DevOps tutorial

# Jenkins Configuration as Code: define credentials in YAML
credentials:
  system:
    domainCredentials:
      - credentials:
          - string:
              scope: GLOBAL
              id: "dockerhub-token"
              secret: ${DOCKERHUB_TOKEN}  # Use environment variable or vault
              description: "Docker Hub access token"
          - usernamePassword:
              scope: GLOBAL
              id: "aws-creds"
              username: ${AWS_ACCESS_KEY_ID}
              password: ${AWS_SECRET_ACCESS_KEY}
              description: "AWS credentials for deployment"