gitlab-ci-variables-secrets

$npx mdskill add TheBushidoCollective/han/gitlab-ci-variables-secrets

Configures GitLab CI/CD variables and manages secrets securely for pipeline automation.

  • Helps with setting up secure credential handling and integrating external secret providers.
  • Integrates with GitLab CI/CD and uses tools like Bash, Grep, and Glob for operations.
  • Decides based on variable types, scopes, and protection settings defined in configurations.
  • Presents results through YAML examples and structured variable management in pipelines.

SKILL.md

.github/skills/gitlab-ci-variables-secretsView on GitHub ↗
---
name: gitlab-ci-variables-secrets
user-invocable: false
description: Use when configuring GitLab CI/CD variables, managing secrets, or integrating with external secret providers. Covers secure credential handling.
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Grep
  - Glob
---

# GitLab CI - Variables & Secrets

Configure CI/CD variables and manage secrets securely in GitLab pipelines.

## Variable Types

### Predefined Variables

```yaml
build:
  script:
    - echo "Branch: $CI_COMMIT_BRANCH"
    - echo "Commit: $CI_COMMIT_SHA"
    - echo "Pipeline: $CI_PIPELINE_ID"
    - echo "Project: $CI_PROJECT_NAME"
    - echo "Registry: $CI_REGISTRY_IMAGE"
```

### Custom Variables

```yaml
variables:
  NODE_ENV: production
  DATABASE_URL: "postgres://localhost/app"

build:
  variables:
    BUILD_TARGET: dist
  script:
    - npm run build --target=$BUILD_TARGET
```

## Variable Scopes

### Global Variables

```yaml
variables:
  GLOBAL_VAR: "available everywhere"
```

### Job-Level Variables

```yaml
deploy:
  variables:
    DEPLOY_ENV: production
  script:
    - ./deploy.sh $DEPLOY_ENV
```

### Environment-Scoped Variables

Configure in GitLab UI: Settings > CI/CD > Variables

- Scope to specific environments (production, staging)
- Scope to specific branches (main, develop)

## Protected and Masked Variables

### In gitlab-ci.yml

```yaml
variables:
  PUBLIC_KEY:
    value: "pk_test_xxx"
    description: "Stripe public key"
```

### In GitLab UI

Set variables with:

- **Protected**: Only available on protected branches/tags
- **Masked**: Hidden in job logs (requires specific format)
- **Expanded**: Allow variable references within value

## File-Type Variables

```yaml
deploy:
  script:
    - cat $KUBECONFIG  # File variable contents
    - kubectl apply -f deployment.yaml
```

## External Secret Providers

### HashiCorp Vault

```yaml
job:
  secrets:
    DATABASE_PASSWORD:
      vault:
        engine:
          name: kv-v2
          path: secret
        field: password
        path: production/db
```

### Azure Key Vault

```yaml
job:
  secrets:
    API_KEY:
      azure_key_vault:
        name: my-api-key
        version: latest
```

### AWS Secrets Manager

```yaml
job:
  secrets:
    AWS_SECRET:
      aws_secrets_manager:
        name: prod/api-key
        version_id: latest
```

## OIDC Authentication

```yaml
deploy:aws:
  id_tokens:
    AWS_TOKEN:
      aud: https://gitlab.com
  script:
    - >
      aws sts assume-role-with-web-identity
      --role-arn $AWS_ROLE_ARN
      --web-identity-token $AWS_TOKEN
```

## Best Practices

1. Never hardcode secrets in `.gitlab-ci.yml`
2. Use protected variables for production credentials
3. Mask sensitive values to prevent log exposure
4. Prefer OIDC over long-lived credentials
5. Scope variables to minimum required environments
6. Use file-type variables for certificates and keys

More from TheBushidoCollective/han

SkillDescription
absinthe-resolversUse when implementing GraphQL resolvers with Absinthe. Covers resolver patterns, dataloader integration, batching, and error handling.
absinthe-schemaUse when designing GraphQL schemas with Absinthe. Covers type definitions, interfaces, unions, enums, and schema organization patterns.
absinthe-subscriptionsUse when implementing real-time GraphQL subscriptions with Absinthe. Covers Phoenix channels, PubSub, and subscription patterns.
act-docker-setupUse when configuring Docker environments for act, selecting runner images, managing container resources, or troubleshooting Docker-related issues with local GitHub Actions testing.
act-local-testingUse when testing GitHub Actions workflows locally with act. Covers act CLI usage, Docker configuration, debugging workflows, and troubleshooting common issues when running workflows on your local machine.
act-workflow-syntaxUse when creating or modifying GitHub Actions workflow files. Provides guidance on workflow syntax, triggers, jobs, steps, and expressions for creating valid GitHub Actions workflows that can be tested locally with act.
ameba-configurationUse when configuring Ameba rules and settings for Crystal projects including .ameba.yml setup, rule management, severity levels, and code quality enforcement.
ameba-custom-rulesUse when creating custom Ameba rules for Crystal code analysis including rule development, AST traversal, issue reporting, and rule testing.
ameba-integrationUse when integrating Ameba into development workflows including CI/CD pipelines, pre-commit hooks, GitHub Actions, and automated code review processes.
analyze-performanceAnalyze performance metrics and identify slow transactions in Sentry