opschain admin secrets providers
Included from Basic tiersecrets:multi-vaultpacks:secrets-awspacks:secrets-azure
Manage the SecretsProvider connections the server resolves
secret-vault:// references through. A provider is a
first-class connection object — kind (openbao | hashicorp-vault | aws-secrets-manager | azure-key-vault — each cloud kind requires its packs:secrets-<cloud> entitlement),
KV engine version, address, auth method (token | userpass | approle)
with an encrypted, write-only credential, TLS options, cipher stacking,
generated-secret length, an enabled flag and per-connection health — with
the same lifecycle treatment as an identity provider connection: audited
writes, a test verb, and admin-plane authorization on every verb.
Multi-vault: the first enabled provider is
base platform; enabling a second requires the secrets:multi-vault
entitlement (the typed FEATURE_ENTITLEMENT_REQUIRED refusal names it).
With several providers enabled, scope bindings (opschain admin secrets bindings) route resolution between them — the root (/) binding names the
estate default, and with several enabled and no root binding, default
resolution refuses by name rather than guessing. A provider referenced by
bindings cannot be deleted until its bindings are removed. With no
provider registered, the local AGE dev store resolves references
best-effort; with every provider disabled, resolution refuses loudly
rather than silently falling back.
The retired vault.* config keys are consumed once at upgrade to seed the
first provider (recommended code vault) — see opschain docs config —
after which this command tree is the only way to manage the backend.
| Subcommand | Purpose |
|---|---|
list | Every provider: kind, address, auth, enabled state, health. |
show <code-or-id> | One provider's full connection facts. |
create <code> | Register a provider (credential via env/prompt, never argv). |
update <code-or-id> | Change fields; a supplied credential rotates the stored one. |
delete <code-or-id> | Remove a provider. |
test <code-or-id> | Probe with the stored credential; outcome recorded as health. |
Every verb rides the v2 SecretsProviderService, which authenticates
user tokens only: the caller's own opschain login session is the
primary credential (a static platform admin token never works on the v2
lane). An explicit --auth-token wins, and OPSCHAIN_ADMIN_TOKEN / the
opschain admin login token remain the fallback for automation that
runs without a login; the server still requires the /admin updatable
determination (a superuser qualifies).
Exit codes: 0 on success, 1 when a call fails or the token is rejected, 2 for usage errors.
See also
opschain docs cli/admin-secrets-providers-create— registering one.opschain docs cli/admin-secrets-providers-test— the health probe.