Skip to main content
Version: v5.6.1

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.

SubcommandPurpose
listEvery 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.