Mounting Generic Secrets

Looking into the definition#

Let’s see how we could mount the Secret we created. For this let us see an updated definition of jenkins.yml. The Definition, limited to the relevant parts, is as follows.

Line 19-20: We added jenkins-creds that mounts the /etc/secrets directory.

Line 24-26: The jenkins-creds Volume references the Secret named my-creds.

Line 27: Since we want the process inside the container to only read the Secret, we set the defaultMode to 0444. That will give read permissions to everyone. Typically, we’d set it to 0400, thus giving the read permissions only to the root user. However, since the Jenkins image uses the jenkins user, we gave read permissions to everyone instead of only to the root user.

Line 29-32: Finally, since the image expected files named jenkins-user and jenkins-pass, we made explicit paths. Otherwise, Kubernetes would create files username and password.

Applying the definition#

Let’s apply the new definition.

We applied the definition and waited until the new objects were rolled out.

Verification#

Now we can check whether the correct files are indeed stored in the /etc/secrets directory.

The output of the latter command is as follows.

The files we need are indeed injected. To be on the safe side, we’ll also check the content of one of them.

The output is jdoe, the username of our newly deployed Jenkins.

Finally, let’s confirm that the application is indeed secured.

You’ll see that, this time, the link to create new jobs is gone.

Please use jdoe and incognito if you’d like to login to your newly deployed and (more) secured Jenkins.

Destroying everything#

For now, we’ll destroy the cluster we used in this chapter.

Try it yourself#

A list of all the commands used in the lesson is given below.