TigerTrust Secrets Manager (SM) is a Vault-compatible engine that runs inside the platform — there is no separate server binary to deploy. On the host side you install a CLI for humans and an agent for workloads.
Unlike CLM (one agent) or PAM (four binaries), SM’s server side lives in the TigerTrust backend. On the client side you install the tt CLI, the SM agent (for templating), or you point existing Vault-compatible tooling at the compat endpoint.
What ships Component Runs on Purpose SM engine TigerTrust backend KV, transit, PKI, database dynamic secrets, wrapping tt secretsAny workstation or CI runner First-class SM CLI vault (or any Vault-compatible client)Anywhere Works against /v1/* compat endpoints tt-secrets-agentAny host / pod Renders secrets into files via templates, handles lease renewal
1. Install the tt CLI Homebrew (macOS/Linux)
apt (Debian/Ubuntu)
rpm (RHEL/Fedora)
Windows (Scoop)
Static binary
brew install tigertrust/tap/tt tt login tt secrets --help
curl -fsSL https://apt.tigertrust.io/gpg | sudo tee /etc/apt/trusted.gpg.d/tigertrust.asc echo "deb https://apt.tigertrust.io stable main" | sudo tee /etc/apt/sources.list.d/tigertrust.list sudo apt-get update && sudo apt-get install tt
sudo dnf config-manager --add-repo https://rpm.tigertrust.io/tigertrust.repo sudo dnf install tt
scoop bucket add tigertrust https: // github.com / tigertrust / scoop scoop install tt
curl -Lo tt https://releases.tigertrust.io/tigertrust-tt/linux-amd64 chmod +x tt && sudo mv tt /usr/local/bin/
Log in and set the workspace:
tt login --api=https://api.tigertrust.io tt workspace use wsp_xxx # Common operations tt secrets read secret/prod/db/password tt secrets write secret/prod/db/password [email protected] tt secrets list secret/prod tt secrets rotate database/roles/prod-postgres
The backend exposes a Vault-compatible surface at /v1/*. Everything you know (vault kv get, vault write, vault token create, vault agent) works against it — set the address and a workspace-scoped token.
export VAULT_ADDR = https :// api . tigertrust . io export VAULT_TOKEN = $( tt tokens issue --ttl=1h ) vault kv get secret/prod/db/password vault write database/creds/prod-postgres # dynamic short-lived creds vault write pki/issue/web-server common_name=web.example.com
Supported v1 paths cover KV v1/v2, transit, PKI, database, AppRole, wrapping, and the standard sys/* endpoints (sys/mounts, sys/policy, sys/health, sys/wrapping/*).
3. Install the SM agent (tt-secrets-agent) The SM agent runs alongside a workload and renders secrets to files or environment variables — the workload never needs to know about SM. It handles token/lease renewal, template re-rendering on secret change, and signalling the child process.
systemd
Kubernetes (sidecar)
Docker Compose
curl -sSf https://releases.tigertrust.io/tigertrust-sm/agent | \ TT_API_URL = https://api.tigertrust.io \ TT_APPROLE_ROLE_ID=... \ TT_APPROLE_SECRET_ID=... \ sh sudo systemctl enable --now tt-secrets-agent
# values.yaml for the sidecar chart approle : roleId : ... secretId : ... templates : - source : /etc/config/db.tpl destination : /run/secrets/db.env
helm upgrade --install tt-secrets-agent tigertrust/sm-agent -f values.yaml
tt-secrets-agent : image : ghcr.io/tigertrust/tt-secrets-agent:latest environment : TT_API_URL : https://api.tigertrust.io TT_APPROLE_ROLE_ID : ${ROLE_ID} TT_APPROLE_SECRET_ID : ${SECRET_ID} volumes : - ./templates:/etc/tt/templates - shared-secrets:/run/secrets
Example template (/etc/tt/templates/db.env.tpl):
DATABASE_URL=postgres://{{ with secret "database/creds/prod-postgres" }}{{ .Data.username }}:{{ .Data.password }}{{ end }}@db.internal:5432/app
The agent renews the lease before it expires and re-renders the template when the secret changes.
4. Auth methods on the client side Which auth method you use depends on where the client runs:
Where Recommended auth CLI flag / env Developer laptop Browser OIDC login tt loginCI runner (GitHub Actions, GitLab CI) JWT / OIDC federation tt login --method=jwt --jwt-token=$TOKENKubernetes pod ServiceAccount JWT tt login --method=kubernetes --role=my-roleGeneric Linux host AppRole VAULT_ROLE_ID, VAULT_SECRET_IDCloud VM Cloud IAM (AWS/Azure/GCP) tt login --method=aws
Configure the auth method under Settings → Secrets Manager → Auth Methods .
SM overview Engines, secrets, leases, and the compat surface.
Rotation policies Scheduled rotation for KV values and database roles.
Policies Vault-syntax HCL policies scoped to the workspace.
Access methods OIDC, JWT, AppRole, Kubernetes, cloud IAM.
