CI/CD Integrations

SyVault Secrets Manager integrates with major CI/CD platforms to inject secrets into build and deployment pipelines without hardcoding credentials in source control. Each integration uses a service account client authenticated with ECDSA-signed JWTs.

Prerequisites

Before configuring any CI/CD integration:

1. Create a Secrets Manager application and client in the web vault (see Applications & Clients).
2. Grant the client read access to the folders containing the secrets your pipeline needs.
3. Note the client_id and bootstrap token -- you will need them during setup.

GitHub Actions

SyVault provides an official GitHub Action that fetches secrets and exposes them as environment variables or step outputs.

For detailed setup instructions, YAML examples, and advanced usage (notation references, masking, multi-folder access), see the dedicated GitHub Actions guide.

Quick example:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: syvault/secrets-action@v2
        with:
          server: https://vault.example.com
          client_id: ${{ secrets.SY_CLIENT_ID }}
          client_secret: ${{ secrets.SY_CLIENT_SECRET }}
          secrets: |
            sy://Production/Database/field/password | DB_PASSWORD
            sy://Production/API/field/key | API_KEY
      - run: ./deploy.sh

GitLab CI

Setup

1. In your GitLab project, go to Settings > CI/CD > Variables.
2. Add SY_CLIENT_ID and SY_CLIENT_SECRET as masked, protected variables.
3. Install the SyVault CLI in your pipeline and use sy exec to inject secrets.

Example .gitlab-ci.yml

stages:
  - deploy

deploy-production:
  stage: deploy
  image: node:20
  before_script:
    - curl -fsSL https://get.syvault.com/cli | sh
    - sy init --client-id $SY_CLIENT_ID --client-secret $SY_CLIENT_SECRET --server https://vault.example.com
  script:
    - sy exec --env DB_PASS=sy://Production/Database/field/password --env API_KEY=sy://Production/API/field/key -- ./deploy.sh
  only:
    - main

The sy exec command fetches each secret, injects it as an environment variable for the wrapped process, and ensures secrets are never written to disk or CI logs.

Jenkins

Setup

1. Install the SyVault CLI on your Jenkins agent or use a Docker image that includes it.
2. Store SY_CLIENT_ID and SY_CLIENT_SECRET in Jenkins Credentials (type: Secret text).
3. Reference them in your pipeline with withCredentials.

Example Jenkinsfile

pipeline {
    agent any
    environment {
        SY_SERVER = 'https://vault.example.com'
    }
    stages {
        stage('Deploy') {
            steps {
                withCredentials([
                    string(credentialsId: 'sy-client-id', variable: 'SY_CLIENT_ID'),
                    string(credentialsId: 'sy-client-secret', variable: 'SY_CLIENT_SECRET')
                ]) {
                    sh '''
                        sy init --client-id $SY_CLIENT_ID --client-secret $SY_CLIENT_SECRET --server $SY_SERVER
                        sy exec \
                          --env DB_PASS=sy://Production/Database/field/password \
                          --env API_KEY=sy://Production/API/field/key \
                          -- ./deploy.sh
                    '''
                }
            }
        }
    }
}

Azure DevOps

Setup

1. In your Azure DevOps project, go to Pipelines > Library and create a variable group.
2. Add SY_CLIENT_ID and SY_CLIENT_SECRET as secret variables.
3. Link the variable group to your pipeline.

Example azure-pipelines.yml

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  - group: syvault-credentials

steps:
  - script: |
      curl -fsSL https://get.syvault.com/cli | sh
      sy init --client-id $(SY_CLIENT_ID) --client-secret $(SY_CLIENT_SECRET) --server https://vault.example.com
    displayName: 'Install and bootstrap SyVault CLI'

  - script: |
      sy exec \
        --env DB_PASS=sy://Production/Database/field/password \
        --env API_KEY=sy://Production/API/field/key \
        -- ./deploy.sh
    displayName: 'Deploy with secrets'

Security Best Practices

• Rotate client secrets regularly. Create a new client and retire the old one on a quarterly schedule.
• Use folder-scoped access. Grant each CI/CD client access only to the folders it needs -- never the entire vault.
• Mask variables. All platforms above support marking variables as secret or masked. Always enable this for client credentials.
• Audit access. Review the Secrets Manager audit log in the Admin Console to verify which secrets your pipelines are reading and when.