GitLab CI Security Best Practices

# CHAPTER 8

GitLab CI Security Best Practices #

1. Introduction #

2. Learning Objectives #

• Identify the security risks of hardcoding credentials in .gitlab-ci.yml.

• Configure secure, masked CI/CD Variables in the GitLab UI.

• Differentiate between standard variables and "Protected" variables.

• Prevent secrets from leaking in pipeline execution logs.

• Enforce the Principle of Least Privilege in CI/CD environments.

3. Beginner Explanation #

• The Insecure Way (Hardcoding): You write the combination to the bank vault in giant letters on the outside of the bag. Anyone walking down the street (or looking at your GitHub/GitLab repository) can read the combination.

• The Secure Way (CI/CD Variables): You put the combination inside a titanium lockbox (GitLab UI Variables). When the courier reaches the bank, a machine reads the lockbox digitally. The courier never sees the combination. Even if the courier tries to write the combination down on their clipboard (The Pipeline Logs), the machine automatically censors it with [MASKED].

4. The Threat: Hardcoded Secrets #

# DO NOT DO THIS. IT IS A CATASTROPHIC VULNERABILITY.
deploy_job:
  script:
    - aws configure set aws_access_key_id "AKIAIOSFODNN7EXAMPLE"

If you push this to GitLab, anyone who can read your repository can steal your AWS key and spin up $50,000 worth of servers overnight to mine cryptocurrency.

5. Securing Secrets via GitLab UI Variables #

1. 1. Go to your GitLab repository -> Settings -> CI/CD.

1. 2. Expand the Variables section.

1. 3. Click Add variable.

1. 4. Key: AWS_ACCESS_KEY

1. 5. Value: Paste the actual secret key here.

1. 6. Check "Mask variable": This is critical. It tells GitLab that if this variable ever accidentally gets printed to the terminal log during a job, GitLab must censor it so developers reading the log cannot see it.

1. 7. Check "Protect variable": This ensures the variable is ONLY available to pipelines running on protected branches (like main). If a hacker creates a feature branch and tries to print the variable, it will be blank.

Now, update your YAML file to use the safe reference:

# SECURE DEPLOYMENT
deploy_job:
  script:
    # GitLab securely injects the vaulted value exactly when the job runs
    - aws configure set aws_access_key_id "$AWS_ACCESS_KEY"

6. Mini Project: Secure Deployment Workflow #

Step-by-Step Walkthrough:

1. 1. In your GitLab project, go to Settings -> CI/CD -> Variables.

1. 2. Create a variable:

• Key: MY_SECRET_PASSWORD

• Value: super_secret_123!

• Ensure Mask variable is checked. Save it.

1. 3. Open your .gitlab-ci.yml file and add this job:

1. 5. Go to the Pipelines dashboard and click on the test_leak_job terminal output.

1. 6. *The Result:* The terminal log will output: The password is [MASKED]. GitLab's security engine successfully detected the sensitive string and intercepted it before it could be logged!

1. 2. Ensure main is protected. Set "Allowed to merge" and "Allowed to push" to "Maintainers" only.

1. 3. If a Junior Developer tries to push a malicious .gitlab-ci.yml file directly to main that attempts to steal the deployment keys, the push will be blocked.

• Masking Short Strings: GitLab's masking algorithm requires the secret value to be at least 8 characters long. If you try to mask a variable with the value 1234, GitLab will throw an error and refuse to save it, because masking extremely short strings can accidentally censor legitimate terminal output (like standard exit codes).

1. 1. Describe the catastrophic risk of committing plaintext credentials directly into a .gitlab-ci.yml` file.

1. 2. Explain the purpose of checking the "Protect variable" box when creating a CI/CD variable in the GitLab UI.

11. FAQs #

12. Summary #

13. Next Chapter Recommendation #