🔐 Secure Secrets in GitLab CI/CD: Best Practices to Manage Secrets in Pipelines

As pipelines evolve from simple demonstration workflows to production-grade automation engines, hardcoding sensitive credentials—such as push tokens, artifact repository keys, and database passwords—presents an unacceptable security vulnerability. This chapter explores how to secure your GitLab CI/CD pipelines by migrating away from plain-text credentials in configuration files, implementing environment-based placeholders, enforcing least-privilege access control, and configuring branch protection rules.

1. Why Do We Need Secret Management in CI/CD?

In earlier pipeline iterations, configuration files (such as .xml or properties files) often contain direct, plain-text credentials for simplicity and demonstration purposes. However, leaving secrets exposed inside repository code commits is a major security risk.

Real-Life Analogy

The Master Key Left on the Front Porch: Hardcoding secrets directly in your codebase or runner files is like leaving your house keys taped to the front door. Anyone who can view the repository (or inspect the runner server) gains immediate, unhindered administrative access to your downstream systems (JFrog Artifactory, production databases, GitLab registries).

The Security Transition

• Naive Approach: Storing usernames, passwords, API keys, and deployment tokens directly inside source files (settings.xml, application properties) and committing them to version control.
• Production Approach: Storing secrets securely in GitLab CI/CD Project Variables, substituting them dynamically via environment variables (env.VAR_NAME), restricting credentials by environment/branch, and scoping permissions to specific deployment targets.

2. Core Mental Model: Centralized Variables vs. Hardcoded Artifacts

To decouple sensitive strings from application source code, we use environment placeholders inside build tools (like Maven) and map them to GitLab CI/CD variables evaluated at runtime.

3. Step-by-Step Evolution: Securing the GitLab Push Token

The first critical secret often found in release workflows is the GitLab push token used for pushing tags or release artifacts back to the repository.

Step 1: Access Project CI/CD Variables

Navigate to your GitLab project: Settings -> CI/CD -> Variables -> Expand -> Add Variable.

Step 2: Configure Variable Flags

When adding a sensitive token, configure the following flags carefully:

• Mask Variable (mask): Hides the raw secret value in job logs. If the secret accidentally gets printed during execution, GitLab masks it with asterisks ([MASKED]).
• Protect Variable (protected): Ensures the variable is exposed only to pipelines running on protected branches (e.g., default branches or release branches like rb_*), blocking unauthorized or feature branch pipelines from accessing production credentials.

Step 3: Define the Variable Key and Value

• Key: GITLAB_PUSH_TOKEN
• Value: <your-actual-push-token>

Step 4: Reference the Variable in Pipeline Scripts

In your .gitlab-ci.yml or shell execution scripts, reference the variable using standard shell syntax:

git push https://oauth2:$GITLAB_PUSH_TOKEN@gitlab.com/your-repo.git

4. Protecting Target Branches in GitLab

To ensure that release jobs and protected variables can only execute in controlled environments, you must configure protected branches.

Repository Branch Protection Setup

1. Go to Settings -> Repository -> Protected branches.
2. Click Add protected branch.
3. Define the branch pattern (e.g., rb_* or a wildcard matching release branches).
4. Configure permissions:
   • Allowed to push: No one (forces developers to use Merge Requests).
   • Allowed to merge: Maintainers (ensures code review compliance before merging into release branches).

5. Granular Secret Segregation: Managing JFrog Artifactory Credentials

Instead of using a single powerful administrator account for all repository publishing tasks, separate your publishing pipeline into Snapshots and Releases using distinct users and privileges.

User Segregation Strategy

Updating Maven settings.xml with Environment Placeholders

Instead of hardcoding credentials in ~/.m2/settings.xml, use Maven's environment interpolation prefix (env.):

<servers>
  <server>
    <id>central-releases</id>
    <username>${env.RELEASE_ARTIFACTORY_USER}</username>
    <password>${env.RELEASE_ARTIFACTORY_PASS}</password>
  </server>
  <server>
    <id>snapshots</id>
    <username>${env.SNAPSHOT_ARTIFACTORY_USER}</username>
    <password>${env.SNAPSHOT_ARTIFACTORY_PASS}</password>
  </server>
</servers>

6. Securing Database Credentials Across Profiles

When applications support multiple deployment profiles (e.g., Test vs. Production), database URLs, usernames, and passwords must also be externalized.

Naive vs. Secure Application Configuration

Naive Approach (Hardcoded Properties):

spring.datasource.url=jdbc:mysql://prod-db.internal:3306/appdb
spring.datasource.username=admin
spring.datasource.password=PlainTextSecret123

Secure Approach (Placeholders):

spring.datasource.url=${PROD_DB_URL}
spring.datasource.username=${PROD_DB_USER}
spring.datasource.password=${PROD_DB_PASSWORD}

GitLab CI/CD Variable Mapping Table

Set up these corresponding variables in GitLab project settings:

7. Complete Flow Walkthrough: From Code Commit to Verified Deployment

When all security measures, protected branches, and variable placeholders are properly configured, a typical production deployment follows this exact sequence:

8. Summary and Key Takeaways

• Eliminate Hardcoded Secrets: Never commit passwords, tokens, or API keys directly into repository files (settings.xml, properties files, or shell scripts).
• Leverage Project Variables: Store all sensitive configuration data inside GitLab CI/CD Project Variables rather than hardcoding them in runner file systems.
• Enforce Masking (mask): Always mask sensitive tokens and passwords to prevent them from leaking into plain-text job console logs.
• Restrict via Protected Variables (protected): Bind production-level credentials exclusively to protected branches (e.g., rb_* or main) to prevent unauthorized pipeline jobs from accessing production keys.
• Implement Least Privilege Access: Separate deployment actors (e.g., creating dedicated Artifactory users for snapshots versus production releases).
• Use Environment Placeholders: Utilize Maven and Spring environment placeholders (${env.VARIABLE_NAME}) so build tools automatically ingest runtime environment variables.
• Automate Merge Requests: Enforce branch protection rules that require Merge Requests and maintainer approvals before code can be merged and deployed to production.
• Future Pipeline Enhancements: As CI/CD maturity grows, integrate automated security components such as Secret Detection, Code Analysis, and Vulnerability Scanning jobs into your pipeline.