CI/CD with Jenkins: steps to use credentials in your Build & Mule app

A Jenkins manager (that is a Jenkins user who administers a Jenkins site) can add/configure credentials in Jenkins. The credentials can be used by pipeline projects to interact with the application and/or build process.

Where to use credentials

Credentials stored in Jenkins can be used:

• Anywhere applicable throughout Jenkins (i.e. global credentials)
• By a specific pipeline project/item
• By a specific Jenkins user (as is the case for pipeline projects created in Blue Ocean)

Types of credentials stored in Jenkins

• Secret text: a token such as an API token (e.g. a GitHub personal access token)
• Username and password: could be handled as separate components or as a colon separated string in the format username:password (read more about this in Handling credentials)
• Secret file: essentially secret content in a file. We’ll be using this type in this article.
• SSH Username with private key: an SSH public/private key pair
• Certificate: a PKCS#12 certificate file and optional password
• Docker Host Certificate Authentication credentials

We’ll be using secret file type credential store for this article.

Configuring credentials

Who can create credentials?

Credentials can be added to Jenkins by any Jenkins user who has the credentials > create permission (set through Matrix-based security). These permissions can be configured by a Jenkins user with the administer permission.

Steps to use Jenkins secret file

Use case

I’ll showcase deployment of a simple mule application to CloudHub. The requirement is to NOT expose the CloudHub credentials anywhere, neither in the application nor in the Jenkins pipeline.

Step 1: Install the Credential and Credential Binding Plugin

• Go to Jenkins > Plugins Manager and select Credentials and Credential Bindings Plugin.



• Download and install the plugins. Jenkins will prompt for a restart after the installation.

Step 2: Create and add secret file in Jenkins

• Create a simple text file without any extension and add the credentials you want to add in the secret file. For this example, I’ll be adding anypoint credentials, along with a sample password key.



• Go To Credentials



• Go to Jenkins > Credentials > System > Global credentials > Add Credentials



• Enter the required fields. For this use case, I’m using the below configuration:



• Upload the created secret file in the above Jenkins section.

Step 3: Creating and adding Jenkins file in the Mule application

• As mentioned above, I’ve created a very simple Mule application with one endpoint. The endpoint will return the values present in the secret file.
• Please note that in general you wouldn’t come across this scenario. I’m using the above endpoint to show that the values can also be accessed in the application as well if required.
• Create a Jenkins file, which will access the secret file credentials and deploy the app to CloudHub using these credentials.

stage('BUILD') {
	environment {
        SECRET_FILE_ID = credentials('secret-file-id')
      }
     steps {
	   echo "####DISPLAYING SECRET_FILE_ID####"
	   echo "Global property file: ${SECRET_FILE_ID}"
	   
	   echo "#####Copying Global property file to src\\main\\resources#####"
	   bat "powershell Copy-Item ${SECRET_FILE_ID} -Destination src\\main\\resources"
	   
	   echo "#####Deleting Local Global property file present in src\\main\\resources#####"
	   bat "powershell Remove-Item src\\main\\resources\\global-dev.properties"
	   
	   echo "#####Renaming Global property file in Jenkins to global-dev.properties#####"
	   bat "powershell Rename-Item src\\main\\resources\\secret_file_jenkins global-dev.properties"
	   
	   echo "#####Creating Mule Application artifact#####"
	   bat 'mvn clean install'
   }
   }

Build stage steps

• Refer to the secret file by id and add it to the environment as SECRET_FILE_ID.
• The two steps below are simply to showcase how to access the properties in the secret file in the application. It’s not a required/necessary step.
• Copy the secret file to the application src/main/resources.
• Replace the application property file with the secret file.

Deploy step

stage('DEPLOY-DEV') { 
      environment {
		CLOUDHUB_ENV = credentials('CLOUDHUB_ENV_SANDBOX')
		ANYPOINT_USERNAME_DEV = credentials('ANYPOINT_USERNAME_DEV')
		ANYPOINT_PASSWORD_DEV = credentials('ANYPOINT_PASSWORD_DEV')
		
      }
      steps {
	   echo "DISPLAYING ALL ENVIRONMENT VARIABLES...."
	   echo "CLOUDHUB_ENV: ${CLOUDHUB_ENV}"
	   echo "ANYPOINT_USERNAME: ${ANYPOINT_USERNAME_DEV}"
	   echo "ANYPOINT_PASSWORD: ${ANYPOINT_PASSWORD_DEV}"
	   echo "#####Initiating Deployment to cloudhub#####"
	   bat "mvn package deploy -Pcloudhub -Denv=dev -DANYPOINT_USERNAME=${ANYPOINT_USERNAME_DEV} -DANYPOINT_PASSWORD=${ANYPOINT_PASSWORD_DEV} -DCLOUDHUB_ENV=${CLOUDHUB_ENV}"
	  
	   echo "################APP SUCCESSFULLY DEPLOYED################"
	   
      }

Deploy stage steps

• Assign the properties of the secret file to environment variables.
• Pass the CloudHub credentials as run time parameters, and deploy to CloudHub.

Conclusion

• As you can see, the properties of the secret file aren’t exposed anywhere during the build process and in the application.
• The contents of the secret file can also be accessed only during the first upload of the file. To update the secret file, the only option is that the administrator, i.e., the user with credential access, uploads a new credentials file.

— By Arpit Singh