Quality Management, Testmanagement, Testautomation, Continuous Integration and Delivery, Jenkins, Consulting, Training, Auditing
Jenkins Integration with protected passwords | Comquent GmbH, Continuous Quality in Software
Blog

Jenkins Integration with protected passwords

By Thursday, der 14. February 2019 No Comments
By
, Jenkins Integration with protected passwords, Comquent GmbH, Continuous Quality in Software

Authors: Dimitrios V. Papadopoulos and Ioannis Gkourtzounis

Introduction 

There is a great need of protecting the passwords and the credentials generally through the project’s procedures. We are going to analyze a way on how to achieve the aforementioned. In our example, we include YAML and Groovy files to create our custom Docker-Jenkins container. If we are going to upload all the files into an SCM the credentials will be visible, something that is a vital security issue.

Git SCM

Before the usage of the docker, we are going to hide our credentials from our Git. The credentials that we really need to protect are the following:

  • Jenkins’ agent credentials (we need to insert them inside a .yaml file)
  • Credentials for accessing our Git account through a Jenkins project (included in the above .yaml file)
  • Jenkins’ admin account credentials (we can save then inside a Groovy script)

Next step is to clone our project on a directory (custom) inside our system (Linux is going to be used for this example). In this directory, we will have to create a file named “.env”.

Another step is to insert the above credentials inside the docker composer file (.yaml format).

Now because of the above script, all the other .yaml files can access the variables that are existed inside the .env file. These variables must be inserted also into the .yaml file that we created in the beginning.

Furthermore, we need to include these passwords inside the Groovy script that we made for the Jenkins’ admin account. The format is going to be different because of the Groovy syntax.

Conclusion

From now on all the passwords are hidden from the SCM (or other repositories) because they are located inside the .env file which is included into the host machine (custom system) something that increase the protection of the whole system. We just saw that, by using a combination of YAML, Groovy and system files we can protect at a high level the instance of our project.

Tip: There is also a different approach through the Vault project. For more, you can check here.