by 
Adding credentials to Jenkins when it is running in Docker container. One of the best practices to have a clean Jenkins without any funky magics is to dockerize the Jenkins. In this way, the Jenkins can be deployed in any infrastructure easily without problems.
To achieve that, however, all Jenkins configurations should be coded. So when rebuilding the Jenkins docker image everything will be in place.
There are two important issues that need to tackle when transforming all Jenkins configurations to code which are:
- Plugins
- Credentials
For plugins, one can create a plugins.txtfile which Jenkins picks up automatically when running it from docker.
But for credentials, especially if you have tons of them, no straightforward and secure approach exists.
Here, we discuss two relatively easy options and discuss the pros and cons of each. These approaches are:
- Custom groovy file
- Jenkins Configuration As Code plugin
Custom Groovy file
When Jenkins is built from a dockerfile, it has the ability to execute all Groovy scripts stored in groovy directory. Groovy scripts are quite flexible and allow users to customize/configure Jenkins as needed.
Writing a Groovy script to import credentials to Jenkins from a file could be a plausible option for many. To do so, here we showcase a script that reads a CSV file contains credentials and add them to Jenkins when executing docker run.
However, we shouldn’t bake credentials in a docker image. To avoid it, need to leverage on docker secret and to use it, need to create either a docker compose file or use docker swarm. In this article, we use the simplest approach possible which is docker compose.
First, we need to create a docker compose which reads credentials from a file, like below:
In the above code, the .csv file is read line by and line and then each line is inserted to Jenkins credentials. Jenkins takes care of encoding the password so we don't need to worry about it.
The structure of the file is like this:username, password, description
Of course, the file can contain more information such as CredentialScope. For that, need to tweak the script as well.
Pros
- High flexibility
- Good for massive credentials import
- Suitable for those that don't want to have too many plugins
Cons
- Can be insecure depends on how the file is imported
- Need to code which is more prone to error
- Can't be used in servers that have FTP, SFTP restrictions
- Need docker compose
Jenkins Configuration as code plugin
Jenkins has a great plugin called "Jenkins Configuration as Code Plugin", which allows us to put all Jenkins configuration in code and keep them in a repository. This is the best approach that can avoid CI/CD server migration hell and we highly recommend it.
The plugins offer a various range of features which surely makes any DevOps engineer happy. One of the goodies is the ability to define all credentials in a YAML file which the plugin picks it up on startup.
A naive approach is to pass all the credentials in the YAML file. But then we have to commit them to the source control which is a wrong approach.
A good practice is to define credentials in a YAML but pass the values through environment variable when running the container. In this approach, we don't also need docker-compose.
Let's look at this example.
First, we need to add configuration-as-code and configuration-as-code-support plugins to our plugins.txt file.
Then need to configure the plugin through the Dockerfile like this:
ENV CASC_JENKINS_CONFIG="/var/jenkins_home/casc_configs"
COPY casc_configs /var/jenkins_home/casc_configs
Then need to define the Jenkins credentials skeleton like this and put it in our credentials.yml file.
As you can see, instead of passing the values we pass environment variable names.
And then define the variable names on host machine like this:
$ export SSH_PRIVATE_KEY = `cat ssh_private_key`
$ export SomeUserPassword = `cat someUserPass`
$ export SecretText = `cat SecretText.txt`
$ export AWS_ACCESS_KEY_ID = `AWS_ACCESS_KEY`
$ export AWS_SECRET_ACCESS_KEY = `someFile`
As you can see, we read the variable value indirectly from a file. This is due to security reasons. If one exports the environment variable directly, the secret will be leaked to BASH history which is dangerous. So, be mindful.
The last step is to pass environment variables when running the Jenkins container, like this:
$ docker run -d -p 80:8080 \
-e SSH_PRIVATE_KEY \
-e SomeUserPassword \
-e SecretText \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
Pros
- Out of box solutions
- Ease of use
- Quick setup
Cons
- Not flexible
- Not suitable when having too many credentials
Verdict
Which approach to use depends highly on the need of the project. But we highly recommend Jenkins configuration as code approach if you need much customization and don't have a stack of credentials.
