CI/CD (Generic)

The SikkerKey CLI works in any CI/CD environment that can run shell commands. The pattern is the same regardless of platform: bootstrap a CI machine, add the credentials to your CI secrets, install the CLI in the pipeline, fetch secrets.

Bootstrap

From the dashboard, go to Machines > + Validate and select the CI/CD tab. Run the command on any machine with openssl and curl:

curl -sSL https://api.sikkerkey.com/v1/bootstrap/YOUR_TOKEN/ci | sh

This prints your vault ID, machine ID, and private key. Add them to your CI system's secret store along with your project ID.

General Pattern

Every CI/CD integration follows three steps:

1. Install the CLI: npm install -g @sikkerkey/cli
2. Configure the identity: write the private key and identity.json from CI secrets
3. Fetch secrets: use sikkerkey run, sikkerkey export, or sikkerkey get

Identity Setup Script

Use this script in any pipeline. It expects four environment variables set from your CI system's secret storage:

#!/bin/sh
set -e

# Install CLI
npm install -g @sikkerkey/cli

# Create identity from CI secrets
VAULT_DIR="$HOME/.sikkerkey/vaults/$SIKKERKEY_VAULT_ID"
mkdir -p "$VAULT_DIR"
chmod 700 "$HOME/.sikkerkey" "$HOME/.sikkerkey/vaults" "$VAULT_DIR"

echo "$SIKKERKEY_PRIVATE_KEY" > "$VAULT_DIR/private.pem"
chmod 600 "$VAULT_DIR/private.pem"

cat > "$VAULT_DIR/identity.json" <<EOF
{
  "machineId": "$SIKKERKEY_MACHINE_ID",
  "machineName": "ci",
  "vaultId": "$SIKKERKEY_VAULT_ID",
  "apiUrl": "https://api.sikkerkey.com",
  "privateKeyPath": "$VAULT_DIR/private.pem"
}
EOF
chmod 600 "$VAULT_DIR/identity.json"

# Connect and unlock
sikkerkey connect "$SIKKERKEY_VAULT_ID"
sikkerkey unlock "$SIKKERKEY_PROJECT_ID"

Required CI Secrets

Jenkins

pipeline {
    agent any
    environment {
        SIKKERKEY_VAULT_ID     = credentials('sikkerkey-vault-id')
        SIKKERKEY_PROJECT_ID   = credentials('sikkerkey-project-id')
        SIKKERKEY_MACHINE_ID   = credentials('sikkerkey-machine-id')
        SIKKERKEY_PRIVATE_KEY  = credentials('sikkerkey-private-key')
    }
    stages {
        stage('Setup') {
            steps {
                sh 'npm install -g @sikkerkey/cli'
                sh './scripts/sikkerkey-setup.sh'
            }
        }
        stage('Deploy') {
            steps {
                sh 'sikkerkey run --all -- ./deploy.sh'
            }
        }
    }
}

CircleCI

version: 2.1

jobs:
  deploy:
    docker:
      - image: cimg/node:20.0
    steps:
      - checkout
      - run:
          name: Install SikkerKey
          command: npm install -g @sikkerkey/cli
      - run:
          name: Configure identity
          command: ./scripts/sikkerkey-setup.sh
      - run:
          name: Deploy
          command: sikkerkey run --all -- ./deploy.sh

Add the four secrets in CircleCI project settings under Environment Variables.

Bitbucket Pipelines

pipelines:
  default:
    - step:
        name: Deploy
        image: node:20
        script:
          - npm install -g @sikkerkey/cli
          - ./scripts/sikkerkey-setup.sh
          - sikkerkey run --all -- ./deploy.sh

Add the secrets in Bitbucket under Repository settings > Pipelines > Repository variables.

AWS CodeBuild

version: 0.2
phases:
  install:
    commands:
      - npm install -g @sikkerkey/cli
  pre_build:
    commands:
      - ./scripts/sikkerkey-setup.sh
  build:
    commands:
      - sikkerkey run --all -- ./deploy.sh

Store the secrets in AWS Systems Manager Parameter Store or Secrets Manager and reference them in the buildspec.

Fetching Secrets

After identity setup, choose how to consume secrets:

Inject and run (recommended)

sikkerkey run --all -- ./deploy.sh

All secrets are injected as environment variables. The child process inherits the current environment plus the secrets.

Export to file

sikkerkey export --format dotenv > .env
source .env
./deploy.sh

Fetch individually

DB_PASSWORD=$(sikkerkey get sk_db_prod password)
API_KEY=$(sikkerkey get sk_api_key)
./deploy.sh

Export as JSON

sikkerkey export --format json > secrets.json

Security Notes

• Store the private key in your CI system's secret/credential storage, never in source code
• The identity is ephemeral: created at the start of the pipeline and discarded when the runner is destroyed
• Every secret read is audit-logged with the machine ID, so you can trace which pipeline run accessed which secrets
• Use a dedicated machine per environment (one for staging, one for production) to maintain audit separation