Every system, application or another solution has some authentication providers. Sometimes it’s a local password storage, sometimes administrator can implement AD (or another LDAP), Radius, OAuth etc. Nobody can reach the system without username and password, private key, secret token etc. Words below are so obvious that I feel stupid for writing them. But anyway it’s a very important entry into my today post – how to create credentials in Jenkins. Because even Jenkins has to use credentials in its projects and builds.
If you have ever used Jenkins, you probably know that you can pass username and password as a parameter. It’s great for the beginners but completely unsafe with a production environment. If you have no idea what about I am talking, take a look at this example:
Passing credentials in the parameters
Let’s create a new project. In this example, we want to connect to the vCenter Server and get a list of all datacenters. When we use parameter for password storing, our project will look like on the following picture (contains only one parameter of “password” type):
As you can see it is possible and even you have something you can call “soft safety”. The password is being displayed not as a plain text, but in the password-type field. Nobody will see your secrets unless he uses browser developer tools. It allows everybody to manipulate the whole front-end code, including the possibility of changing fields type (of course not on the server side). So let’s open our developer tools, navigate to the field with password and change type from “password” to “text”:
Whoa! I see dead peop… khem… I see the password! It’s a simple and obvious trick, so as you can see it’s not safe to use this method. But don’t worry. Jenkins has its own mechanism for storing passwords – username/pass pair, secret files, tokens etc. With an additional plugin, you can use them in your project to provide safe passing credentials.
How to create credentials in Jenkins?
Some theory…
Probably everything in Jenkins is based on the plugins. Also, possibility to store credentials depends on the plugin – Credential Plugin. I won’t discuss it in details, so you can read Jenkins Wiki if you are interested in. In a nutshell, the plugin allows you to store your credentials and also organize them in many domains. It does not mean an Active Directory domain of course. Domain, in this case, is the mechanism which is used for the logical organize groups of passwords, files, and another authentication data. According to the Plugin Wiki page:
For example, you may use the same username with a different password on multiple services. e.g. Wile E Coyote may have an account with Acme Industries, Jenkins CI, etc. in each case using the same username but a different password.
If you need to select the credentials to use when connecting to a service, it can be difficult to ensure that you select the correct one. Selecting the wrong one may mean that the incorrect password triggers a service lockout.
Credential Domains are a solution to help with this problem.
At the beginning, you start with one, Global domain. In fact, it’s not a domain literally, but the place, where you can collect all of these credentials, which should be independent of the domains’ configuration. For my purpose, I will create a credential with the username and password of the vCenter Server to which I want to connect, and I will do it in “Global credentials” (just for show you how it works).
…and a little practice!
At first, you need to find the “Credentials” in the left menu on the main page.
As you can see you can add new domain from this menu. But now we focus on the simple credential creation in the “Global credential” group. If you do not have other domains, you should see the table with the only one row:
Now you can enter the “Global credentials (unrestricted)” link. You will see the following screen (please look especially at the left menu):
There you have the possibility to create a new credential. You just need to use “Add Credentials”. Here you can specify the type of your credentials. The valid options are:
- Username with password – simple pair of the username and password
- SSH username with private key – username with private key for passwordless connections
- Secret file – file with credentials store in
- Secret text – for example, some kind of token
- Certificate – an SSL certificate in the PKCS#12 format
Depending on what you choose, you will have different options to configure. In my case, I need simple username and password pair, so I choose “Username with password”.
Now just click ok and it’s done! You can create credentials in Jenkins fast and easily.
What is the Scope?
The scope allows you to choose between Global and System options. The first one should be used for credentials you want to use in nodes configurations, projects, builds, jobs and much more. If some object inherits configuration from its parent, credentials from Global scope can be used. System scope is more restricted. Credentials are available only for that object, which is associated with that secrets. This scope is useful for example in working with nodes and their communication with the master node. System scope prevents nodes credentials from using them in the jobs.
Are my credentials safe?
I’m sure you wonder whether is it safe? Are credentials encrypted or just hashed? Can somebody do the same trick with changing field value? The answer is: credentials are quite safe. They are encrypted (just try to decode them with some Base-64 tool), but of course nobody can guarantee full security. Some weird thing is that Jenkins returns encrypted value in the form field. Fortunately, it’s not the plain text and changing field type will not give you any interesting things.
If you want, you may explore the code of Jenkins on GitHub – you will find more details of how Jenkins encrypts strings. I also recommend this short article about credential storing – it’s quite old, but after the fast code review I must say that there are many common things.
Short summary
Jenkins stores credentials as encrypted objects. You can use Credentials Plugin for creating, managing and organizing your secrets. The plugin allows you to use passwords, public keys, tokens or the whole files. It’s not recommended to use passwords as the parameters of the build.