DevSecOps series No 4 — Protecting environment variables in the most well-known C.I. systems
In a C.I. / C.D. pipeline is very a common task to use environment variables as a way to store service credentials (like AWS Secret keys or database user/password).
Most used and well-known automation systems have specific features to manage sensitive information.
In this post, I’ll cover the four most common automation systems.
Jenkins
Jenkins calls these sensitive data as secrets and stores them in a specific path ($JENKINSHOME/secrets/). Secrets are stored using AES encryption.
Jenkins needs specific integration with the programming language to get the plain version of the encrypted password.
You can check Jenkins documentation for additional information.
GitHub Actions
GitHub actions use a special environment variable called secrets. Variables marked as secrets will not be displayed in logs and will be stored encrypted.
To set up secrets you need to add each variable on the settings project page.
After that, you can use the secret using GitHub syntax:
You can check Github documentation for additional information.
GitLab C.I. / C.D.
GitLab uses a special environment variable called protected variables. Variables marked as protected will not be displayed in logs.
Protected variables values will be encrypted using aes-256-cbc and stored in the database and only can be read and decrypted with a valid secrets file.
To set up protected variables you need to add each variable on the settings project page.
After that, you can use the variables as a regular variable:
You can check GitLab documentation for additional information.
BitBucket pipelines
Like GitLab, BitBucket uses a special environment variable called secured variables. Variables marked as secure will not be displayed in logs and will be stored encrypted.
To set up secured variables you need to add each variable on the settings project page:
After that, you can use the variables as a regular variable:
You can check BitBucket documentation for additional information.
Conclusions
Manage sensitive data sourced from critical systems is a common task in the C.I. / C.D. systems.
Usually, users forget that these sensitive data are from production systems and should be managed very carefully.
All automation systems have their own way of managing sensitive information and are very easy to use them. We only must be careful and educate developers that still do not use them.
More posts about DevSecOps series
Previous post: DevSecOps series No 3 — Old-fashion issues in DevOps: Zip Bombs
