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:

Variant	Tools	Use when
CLI	provider CLI (`aws` / `az` / `vault` / `gcloud`)	the CLI is already on the broker host
curl / REST	`curl` + `jq` (AWS also needs `openssl`+`xxd`)	minimal container images, no CLI
PowerShell	`Invoke-RestMethod`	Windows or mixed-OS broker hosts

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

Never log secret values. The scripts log destination names and status only. Scope the destination credentials tightly (write access to one secret), and prefer instance profiles, Workload Identity, and IRSA over long-lived static keys.

Common Variable

Variable	Description
`SECRET_VALUE`	The value to write — injected automatically by the Britive platform

Destination Configuration

Script: Secret synchronization/aws/sync-to-aws-secrets-manager.sh

Variable	Required	Description
`AWS_SECRET_NAME`	Yes	Name or ARN of the target secret
`AWS_REGION`	Yes	e.g. `us-east-1`
`AWS_PROFILE`	No	Named CLI profile (CLI variant)
`AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY` / `AWS_SESSION_TOKEN`	curl variant	Static / STS credentials

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

The CLI variant uses the standard AWS credential chain. The curl variant signs requests with AWS Signature V4 (needs openssl and xxd).

Script: Secret synchronization/azure/sync-to-azure-key-vault.sh

Variable	Required	Description
`AZURE_VAULT_URL`	Yes	e.g. `https://myvault.vault.azure.net`
`AZURE_SECRET_NAME`	Yes	Target secret name
`AZURE_TENANT_ID` / `AZURE_CLIENT_ID` / `AZURE_CLIENT_SECRET`	curl + PS1	Service principal credentials
`AZURE_SECRET_CONTENT_TYPE` / `AZURE_SECRET_EXPIRES`	No	Optional metadata

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

The CLI variant authenticates via the existing az session (managed identity or service principal).

Script: Secret synchronization/hashicorp/sync-to-hashicorp-vault.sh

Variable	Required	Description
`VAULT_ADDR`	Yes	e.g. `https://vault.example.com:8200`
`VAULT_TOKEN`	Yes (or AppRole)	Token with write access to the path
`VAULT_SECRET_PATH`	Yes	KV path, e.g. `secret/my-app/database`
`VAULT_SECRET_KEY`	Yes	Key within the KV secret, e.g. `password`
`VAULT_ROLE_ID` / `VAULT_SECRET_ID_AR`	AppRole alt.	Use instead of `VAULT_TOKEN`
`VAULT_NAMESPACE` / `VAULT_KV_VERSION` / `VAULT_MOUNT_PATH`	No	Defaults: KV v2, mount `secret`

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

Script: Secret synchronization/gcp/sync-to-gcp-secret-manager.sh

Variable	Required	Description
`GCP_PROJECT_ID`	Yes	GCP project ID
`GCP_SECRET_NAME`	Yes	Secret resource name
`GCP_SA_KEY_FILE` / `GCP_ACCESS_TOKEN`	Auth	SA key file or OAuth2 token
`GCP_DISABLE_PREVIOUS_VERSIONS`	No	`true` to disable older versions after sync

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

If neither auth variable is set, the script falls back to the GCE/GKE/Cloud Run metadata server.

Configure in the Broker

Assign the script as the checkout action on the relevant broker resource profile and set the destination variables as broker parameters. SECRET_VALUE is injected automatically.

broker-config.yml

checkout:
  script: sync-to-aws-secrets-manager.sh
  env:
    AWS_SECRET_NAME: "my-app/database/password"
    AWS_REGION:      "us-east-1"

Verify

Trigger a checkout

Check out the profile that runs the sync script (or rotate the source secret in the Britive vault).

Read the destination value

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

The returned value matches the current Britive-managed secret.

Confirm no secret leaked to logs

Check the broker logs — they show destination and status, never the value of SECRET_VALUE.

Troubleshoot

Symptom	Cause	Fix
`AccessDenied` writing the secret	Destination credentials too narrow or wrong	Grant write on the specific secret only; verify the role/principal
curl variant fails to sign (AWS)	`openssl`/`xxd` missing	Install both, or switch to the CLI variant
Value written but app sees old value	App caches the secret	Confirm the app re-reads on rotation; check the store’s version history
Empty value written	`SECRET_VALUE` not injected	Confirm the script runs as a Britive checkout action, not standalone

Next Steps

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

Last updated on July 8, 2026