CI/CD Platforms

VeraID provides native integrations with all major CI/CD platforms to inject secrets at runtime, enforce access policies, and maintain a complete audit trail of credential usage across your build and deployment pipelines.

Key Features

All CI/CD integrations share these core capabilities:

• Dynamic Secrets — Credentials are fetched at runtime and never stored in your CI/CD platform. Each build receives short-lived, scoped credentials that expire after the job completes.
• Automatic Rotation — When credentials are rotated in VeraID, pipelines automatically receive the latest version on their next run. No manual updates required.
• Full Audit Trail — Every secret access is logged with the pipeline name, run ID, commit SHA, and triggering actor for complete traceability.
• Policy Enforcement — Access policies are evaluated at fetch time. Pipelines can be restricted by branch, environment, time window, or IP range.

Tip

Create a dedicated CI/CD identity in VeraID for each pipeline or repository. This provides granular audit trails and allows you to apply the principle of least privilege to each pipeline independently.

---

GitHub Actions

Use the official veraid/secrets-action to inject secrets into your GitHub Actions workflows.

Setup

1. Create a CI/CD identity in VeraID for your repository.
2. Generate an API key scoped to the secrets you need.
3. Add the API key as a GitHub repository secret named VERAID_API_KEY.
4. Add the identity ID as VERAID_IDENTITY_ID.

Usage

name: Deploy Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Fetch secrets from VeraID
        uses: veraid/secrets-action@v1
        with:
          api-key: ${{ secrets.VERAID_API_KEY }}
          identity-id: ${{ secrets.VERAID_IDENTITY_ID }}
          secrets: |
            DATABASE_URL=db/production-url
            AWS_ACCESS_KEY_ID=aws/access-key-id
            AWS_SECRET_ACCESS_KEY=aws/secret-access-key
            DEPLOY_TOKEN=deploy/production-token

      - name: Deploy
        run: |
          echo "Deploying with fetched credentials..."
          ./scripts/deploy.sh
        env:
          DATABASE_URL: ${{ env.DATABASE_URL }}
          AWS_ACCESS_KEY_ID: ${{ env.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ env.AWS_SECRET_ACCESS_KEY }}
          DEPLOY_TOKEN: ${{ env.DEPLOY_TOKEN }}

The secrets input maps environment variable names to VeraID secret paths using the format ENV_VAR=secret/path. Each secret is fetched individually and masked in logs automatically.

Caution

Never print or echo environment variables containing secrets in your workflow logs. The action automatically registers secrets with GitHub’s log masking, but custom scripts should avoid logging sensitive values.

---

GitLab CI

Use the veraid/ci-helper Docker image to inject secrets into your GitLab CI pipelines.

Setup

1. Create a CI/CD identity in VeraID for your GitLab project.
2. Add the following CI/CD variables in your GitLab project settings:
   • VERAID_API_KEY — Your VeraID API key (masked, protected).
   • VERAID_IDENTITY_ID — Your VeraID identity ID.

Usage

stages:
  - build
  - deploy

variables:
  VERAID_BASE_URL: "https://app.veraid.io"

.fetch-secrets: &fetch-secrets
  image: veraid/ci-helper:latest
  before_script:
    - eval $(veraid secrets export --format=shell)

build:
  <<: *fetch-secrets
  stage: build
  script:
    - echo "Building with injected secrets..."
    - npm ci
    - npm run build
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-production:
  <<: *fetch-secrets
  stage: deploy
  script:
    - veraid secrets export --format=env --output=.env
    - ./scripts/deploy.sh
  environment:
    name: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

The veraid secrets export command supports multiple output formats:

Format	Flag	Description
Shell	--format=shell	Exports as export KEY=VALUE statements for eval
Env file	--format=env	Writes a .env file compatible with Docker and dotenv
JSON	--format=json	Outputs a JSON object for programmatic consumption

---

CircleCI

Use the official veraid/secrets orb to fetch secrets in your CircleCI pipelines.

Setup

1. Create a CI/CD identity in VeraID for your CircleCI project.
2. Add the following environment variables in your CircleCI project settings:
   • VERAID_API_KEY
   • VERAID_IDENTITY_ID

Usage

version: 2.1

orbs:
  veraid: veraid/secrets@1.0

workflows:
  deploy:
    jobs:
      - build:
          context: production

jobs:
  build:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - veraid/fetch-secrets:
          secrets: |
            DATABASE_URL=db/production-url
            API_SECRET=api/secret-key
            DEPLOY_KEY=deploy/production-key
      - run:
          name: Build application
          command: |
            npm ci
            npm run build
      - run:
          name: Deploy
          command: ./scripts/deploy.sh

The veraid/fetch-secrets command injects secrets as environment variables into subsequent steps. Secrets are automatically masked in CircleCI output.

---

Jenkins

Pipeline Plugin

Install the VeraID Jenkins plugin from the Jenkins Plugin Manager. The plugin provides a withVeraIDSecrets pipeline step that injects credentials into the build environment.

pipeline {
    agent any

    environment {
        VERAID_API_KEY = credentials('veraid-api-key')
        VERAID_IDENTITY_ID = credentials('veraid-identity-id')
    }

    stages {
        stage('Build') {
            steps {
                withVeraIDSecrets(
                    secrets: [
                        [envVar: 'DATABASE_URL', path: 'db/production-url'],
                        [envVar: 'AWS_ACCESS_KEY_ID', path: 'aws/access-key-id'],
                        [envVar: 'AWS_SECRET_ACCESS_KEY', path: 'aws/secret-access-key']
                    ]
                ) {
                    sh 'npm ci && npm run build'
                    sh './scripts/deploy.sh'
                }
            }
        }
    }
}

Note

The withVeraIDSecrets block automatically cleans up injected environment variables when the block exits, preventing secret leakage to subsequent stages.

---

Azure DevOps

Service Connection

VeraID integrates with Azure DevOps through a custom service connection type.

1. Install the VeraID extension from the Azure DevOps Marketplace.
2. Create a new service connection of type VeraID in your project settings.
3. Provide your VeraID API key and identity ID.
4. Use the VeraIDSecrets@1 task in your pipeline:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: VeraIDSecrets@1
    inputs:
      serviceConnection: 'veraid-production'
      secrets: |
        DATABASE_URL=db/production-url
        STORAGE_KEY=azure/storage-key
    displayName: 'Fetch secrets from VeraID'

  - script: |
      npm ci
      npm run build
      ./scripts/deploy.sh
    displayName: 'Build and deploy'
    env:
      DATABASE_URL: $(DATABASE_URL)
      STORAGE_KEY: $(STORAGE_KEY)

---

Bitbucket Pipelines

Pipeline Variables

Use the VeraID CLI pipe to inject secrets into your Bitbucket Pipelines.

image: node:20

pipelines:
  branches:
    main:
      - step:
          name: Deploy Production
          deployment: production
          script:
            - pipe: veraid/secrets-pipe:1.0
              variables:
                VERAID_API_KEY: $VERAID_API_KEY
                VERAID_IDENTITY_ID: $VERAID_IDENTITY_ID
                SECRETS: >
                  DATABASE_URL=db/production-url
                  DEPLOY_TOKEN=deploy/production-token
            - source .veraid-env
            - npm ci
            - npm run build
            - ./scripts/deploy.sh

The pipe writes secrets to a .veraid-env file that you source in subsequent commands. The file is automatically deleted at the end of the step.

---

Best Practices

Dedicated Identity per Pipeline

Create a separate VeraID identity for each CI/CD pipeline or repository. This provides:

• Granular audit trails — Know exactly which pipeline accessed which secret.
• Scoped permissions — Each pipeline only has access to the secrets it needs.
• Independent rotation — Rotate credentials for one pipeline without affecting others.
• Blast radius containment — If a pipeline is compromised, only its scoped secrets are at risk.

# Create a dedicated identity for your deploy pipeline
curl -X POST https://app.veraid.io/api/v1/identities \
  -H "Authorization: Bearer kd_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github-deploy-myapp-prod",
    "type": "CI_CD",
    "description": "GitHub Actions deploy pipeline for myapp production",
    "tags": ["ci-cd", "github", "production", "myapp"],
    "metadata": {
      "repository": "org/myapp",
      "branch": "main",
      "platform": "github-actions"
    }
  }'

Additional Recommendations

• Use JIT credentials for deployment pipelines that run infrequently. JIT credentials automatically expire after the specified duration.
• Set IP allowlists to restrict secret access to your CI/CD platform’s IP ranges.
• Enable anomaly detection to alert on unusual access patterns such as off-hours builds or unexpected regions.
• Tag identities consistently with repository, environment, and team metadata for easy filtering and governance.

Danger

Never hardcode VeraID API keys in your pipeline configuration files or commit them to source control. Always use your CI/CD platform’s native secret storage for the VeraID API key itself.