Version: v5.7.0

opschain admin secrets bindings

Included from Basic tiersecrets:multi-vault

Manage the secrets-provider scope bindings that route secret resolution under multi-vault: a binding is a declared scope path → provider mapping — declared and auditable, never inferred — with / binding the estate default, /projects/<code> and /projects/<code>/environments/<code> overriding it down the node tree, the deepest covering scope winning. Which node's binding an unprefixed secret-vault:// reference resolves through follows where the value came from: a reference entered in a project's, environment's or asset's own properties resolves through the binding of the node it was entered on; a reference committed in the template's repository, or supplied as a per-run override, resolves through the binding of the node resolving it. secret-vault://origin@<path>/<key> pins a reference to the supplying node and secret-vault://here@<path>/<key> to the resolving node regardless of layer; the provider-qualified form secret-vault://<code>@<path>/<key> is the explicit cross-provider escape hatch and wins over every rule (origin and here are reserved codes).

Declaring a binding (set) requires the secrets:multi-vault entitlement — the first enabled provider is base platform, multiples and their bindings are the entitled capability. delete is deliberately ungated so a lapsed estate can always unwind. Every write is audited (api:secrets_provider_bindings:*).

Subcommand	Purpose
`list`	Every declared binding with its provider's enabled state and health.
`set <scope-path>`	Declare (or re-point) the binding for a scope path.
`delete <scope-path>`	Remove a binding (the scope falls back to the default).
`resolve <node-path>`	Which provider governs a node path, and which scope decided.

See also​

See also