Cloud Native CI/CD with GitLab

Managing and Storing Secrets and Sensitive Information

In one of our previous examples, while we were learning how to use the .pre and .post stages, we used Slack in the post-test job. This is how our code looked like:

# Post a message to Slack when the pipeline completes
post-test:  
  stage: .post  
  script:    
    - >
      curl -X POST
      -H 'Content-type: application/json'
      --data '{"text":"Pipeline completed"}'
      "https://hooks.slack.com/services/xxxxx/yyyyy/zzzzz"

There's a problem with this approach and it is the fact that we exposed the Slack webhook URL in the .gitlab-ci.yml file. This is considered a security risk because anyone with access to the repository can see the webhook URL and use it to post messages to Slack. The URL should be kept secret. In other scenarios, the URL could be a database password, an API key, or any other sensitive information. These information are not only stored in the .gitlab-ci.yml file but can also show up in the pipeline logs. If you are sending logs to a third-party service, the same information could be exposed to these services as well.

ℹ️ To store secret and sensitive information in GitLab, you should use variables instead of hardcoding them in the CI/CD configuration file.

Go to your project, click on Settings -> CI/CD -> Variables and add a new variable by clicking on the Add variable button. Note that these variables can be set at the project, group, or instance level. In our case, we will set a project-level variable.

ℹ️ Group-level variables are inherited by all projects in the group, while instance-level variables are inherited by all projects in your GitLab instance.

When adding a variable, there are different options you must set:

• Type: The type of the variable. It can be Variable or File. If you select File, you can upload a file containing the secret information. We will use the Variable type in this example.

• Environments: The environments for which the variable is available. You can select All or specify a specific environment. We will select All in this example.

• Visibility: The visibility of the variable. It can be Visible or Masked. If you select Visible, the variable will be displayed in the pipeline logs. If you select Masked, the variable will be hidden in the pipeline logs. If you choose Masked and hidden, the variable will be masked in the logs and you will never be able to reveal it in the UI after saving it. We will select Masked in this example.

• Flags: The flags for the variable. You can select Protect variable to export the variable to pipelines running on protected branches or tags only. You can also select Expands variable reference, this will treat $ as the start of a reference to another variable. For example, you can create a variable called BASE_URL with the value https://example.com and another variable called API_URL with the value $BASE_URL/api. When you use the API_URL variable in your pipeline, it should expand to https://example.com/api thanks to the Expands variable reference flag. We can activate both flags in this example. We are using the main branch which is protected by default. If you have changed this setting, you can deactivate the Protect variable flag.

• Description: A description of the variable. This is optional. We will use Slack webhook URL as the description in this example.

• Key: The key of the variable. This is the name of the variable. We will use SLACK_WEBHOOK as the key in this example.

• Value: The value of the variable. This is the secret information you want to store. We will copy and paste the Slack webhook URL in this field.

Once the variable is added, we will rewrite the .gitlab-ci.yml with the SLACK_WEBHOOK variable without replacing its value (we will keep $SLACK_WEBHOOK):