How I secured sensitive information in GitLab environment variable and made pipeline secured
Tags: gitlab, cicd, bas64, security
Published: 2023-01-20 15:00:49


---
title: How I secured sensitive information in GitLab environment variable and made pipeline secured
published: true
date: 2023-01-20 06:15:57 UTC
tags: #gitlab, #cicd, #bas64, #security
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3rvniigq1q9cvegl1wj8.jpeg
canonical_url: https://cloudifydevops.com/secured-gitlab-pipeline-with-base64
---

While working on my current project, I was facing some issues regarding GitLab CI/CD values which were getting exposed in the pipeline logs. I was looking for a solution and found that it can be achieved with the variable "masked" option. I wanted to mask a server key but it was not possible because that key has multiline values and according to the rules, the "masked" option can only be enabled on single-line variable values. So, finally, I figured out that I can achieve this using Base64. In this article, I will explain how to store sensitive data as an environment variable and secure a GitLab CI/CD pipeline by base64 encoding and decoding.

# What is Base64?

A file (such as an image or video) can be converted into a string of text using Base64 so that it can be transferred over the internet. This is accomplished by taking the file's binary contents and turning it into a set of 64 text-usable characters. In this way, the file can be transmitted as text and still be converted back to its original format once it is retrieved. It's similar to delivering someone a gift wrapped in paper and then having them open the package to retrieve the real gift. In email attachments and when embedding files in HTML, CSS, or JavaScript, Base64 is frequently utilized.

# GitLab environment variable

GitLab CI/CD environment variables are used to safely store and manage sensitive data that is required by the pipeline, such as API keys, passwords, and other configuration parameters. You may reduce the security risk of hardcoding sensitive information into your pipeline definition by using environment variables.

While setting up an environment variable, GitLab CI/CD provides a "masked" option that can hide the value of an environment variable from the pipeline logs. This is helpful if we don't want sensitive data, such as passwords and API credentials, to be shown in the pipeline logs. When the "masked" option is on, a variable's value is changed to \*\*\*\*\* In the pipeline logs.

# Secured pipeline with Base64

Though the "masked" is really an amazing feature of GitLab CI/CD variables, it can't be enabled on multiline variable values. Here comes Base64 which converts the multiline variable values into encoded single-line variable values and after that, I enabled the "masked" option. In the case of single-line values, we can also use Base64 to make it more secure in the pipeline. To mask a variable, there are some certain rules. The variable's value must:

- A single line.

- Characters from the Base64 alphabet (RFC4648).

- The `@`, `:`, `.`, or `~` characters.

### How to use Base64

The base64 command-line utility is often pre-installed if you are using a popular Linux distribution like Ubuntu, Debian, CentOS, or Red Hat. There shouldn't be any more actions for you to take.

If you are using Max OS, you can use the HomeBrew command to install base64:

```
brew install base64

```

### Encoding with base64

To encode a variable, you can use this command:

```
echo -n "insert_your_variable" | base64

```

The output of the command is:

```
aW5zZXJ0X3lvdXJfdmFyaWFibGU=

```

- The "echo" command is showing the variable's value in the terminal

- "-n" is a subcommand for echo which is telling not to append a newline character to the end of the output otherwise it would additionally append a newline character which will also be encoded by base64 and creates additional problems during decoding.

- | is known as a 'pipe' operator which takes the output of one command and makes the input for another command. In this command, this operator is passing the output of echo -n "insert\_your\_variable" as the input of the base64 command.

After encoding, add that value as a CI/CD environment variable with the "masked" option enabled.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1674192856517/ce43f3e9-4de8-43a3-b8d4-a65a421d759e.png)

### Decoding with Base64

To decode a variable in the terminal, just use this command with the "-d" or "--decode" after base64:

```
echo "insert_your_variable" | base64 -d

```

So, now I am going to show how we can decode the value in the GitLab CI/CD pipeline. We need to use the base64 command to decode our base64-encoded value kept in a variable named **SECRET\_KEY** in a GitLab pipeline. I am giving a project-level example below:

```
stages:
  - deploy

deploy:
  stage: deploy
  script:
    - echo "$SECRET_KEY" | base64 -d
    - export DECODED_SECRET_KEY="$SECRET_KEY"

```

The pipeline in this illustration has just one stage, named deploy. At the project level, the variable is stored as **SECRET\_KEY**.

The pipeline initially uses the base64 command to decode the value contained in **SECRET\_KEY** in the script section of the deploy step. After that, the decoded value is then exported and stored in the variable **DECODED\_SECRET\_KEY** so that it can be used later in the pipeline.

# Conclusion

In this article, you have learned how to do base64 encoding for a variable and stored it in GitLab CI/CD environment variable with the "masked" option. Also, how to decode it in the GitLab pipeline without showing the variable's value in the pipeline logs.

It's crucial to note that using plain text to keep secret keys in your pipeline is not recommended; instead, it's more secure to use GitLab's secret variable feature to store the keys and use them in the pipeline.

* * *

I appreciate you taking the time to read this. If you do have still some confusion regarding this article, please let me know in the comments! Also, If you liked this article, consider following me for my latest publications and also follow me on [**Medium**](https://medium.com/@nayeem.ridoy) [**Twitter**](https://twitter.com/ShaMdNayeem) & [**LinkedIn**](https://www.linkedin.com/in/shanayeem/).