Getting Started

Overview

Britive Secrets Vault owns credential policy, versioning, rotation schedules, and access governance. Secret synchronization scripts push the current secret value to a downstream store whenever the broker executes a checkout. The Britive platform calls the broker script and injects the secret and configuration as environment variables; the script only writes to the destination — it never calls back to Britive. The downstream store always reflects the latest Britive-managed value.

What you’ll accomplish:

• Choose a script variant (CLI, curl/REST, or PowerShell) for your destination
• Wire the script as a broker checkout action
• Verify the synced value lands in the external store

How It Works

    flowchart TD
    Vault["Britive Secrets Vault<br/>(source of truth: rotation, versions,<br/>access governance, lifecycle)"]
    Sync["sync-to-*.sh / .ps1<br/>(runs on the broker)"]
    AWS["AWS Secrets Manager"]
    Azure["Azure Key Vault"]
    Hashi["HashiCorp Vault (KV)"]
    GCP["GCP Secret Manager"]

    Vault -->|"checkout triggered — Britive injects SECRET_VALUE + config"| Sync
    Sync --> AWS
    Sync --> Azure
    Sync --> Hashi
    Sync --> GCP
  

Each destination ships three variants:

Before You Begin

• The Access Broker is deployed and connected
• A secret managed in the Britive Secrets Vault
• Write access on the destination store, scoped to the specific secret being synced
• The tools for your chosen variant installed on the broker host

How the Broker Passes Values to a Script

Every broker script — sync, scan, checkout, or rotation — reads its input from environment variables. Nothing is passed on the command line. There are three sources, and knowing which one a value comes from tells you what name to read it under.

Resource attributes arrive with a RESOURCE_ prefix

A resource type defines parameters (host, region, base_dn), and each resource fills them in. When the broker runs a script for that resource, it injects every attribute upper-cased and prefixed with RESOURCE_:

The prefix keeps a resource attribute from colliding with an ordinary shell variable such as PATH or HOME. It applies to every action the broker runs against that resource — scan, checkout, checkin, and rotation alike.

Because the prefix is fixed, a script that must also run by hand reads its own name first and falls back to the prefixed one:

# A value set directly wins, so the script stays runnable outside the broker.
AWS_REGION="${AWS_REGION:-${RESOURCE_REGION:-}}"
AD_HOST="${AD_HOST:-${RESOURCE_HOST:-}}"

Permission and rotation variables arrive under their exact name

Variables configured on the permission or on the rotation reach the script under exactly the name you typed — no prefix, no case change. Configure one called AWS_SECRET_KEY and the script reads $AWS_SECRET_KEY.

Mark a variable encrypted and the broker decrypts it in memory just before the script runs. It never appears in the broker request log, which is how a generated password reaches a script safely.

Platform-supplied variables

Destination Configuration

export AWS_SECRET_NAME="my-app/database/password"
export AWS_REGION="us-east-1"
./sync-to-aws-secrets-manager.sh   # SECRET_VALUE injected by Britive

export AZURE_VAULT_URL="https://myvault.vault.azure.net"
export AZURE_SECRET_NAME="db-password"
./sync-to-azure-key-vault.sh

export VAULT_ADDR="https://vault.example.com:8200"
export VAULT_SECRET_PATH="secret/my-app/database"
export VAULT_SECRET_KEY="password"
./sync-to-hashicorp-vault.sh

export GCP_PROJECT_ID="my-project"
export GCP_SECRET_NAME="my-app-db-password"
./sync-to-gcp-secret-manager.sh

Configure in the Broker

config:
bootstrap:
  tenant_subdomain: mycompany
  authentication_token: "<broker-pool-token>"
resource_types:
Secret-Sync:
  Sync-To-AWS-Secrets-Manager:
    max_supported_version: local
    checkout_script: /opt/britive-broker/scripts/sync-to-aws-secrets-manager.sh

Verify

aws secretsmanager get-secret-value \
  --secret-id "my-app/database/password" \
  --query SecretString --output text

Troubleshoot

Next Steps

Synchronization pushes a value Britive already holds. Rotation changes the value at the source and records the new one:

• Rotate AWS Secrets Manager Secrets — replace the value held in a secret, optionally changing the account behind it first
• Rotate Active Directory Accounts — reset an AD password over LDAPS and propagate it to Secrets Manager or a Windows service

Also:

• Deploy the Access Broker if you haven’t already
• Source: britive/access-broker-examples — Secret synchronization