vault v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-vault-service-token

Custody

customer_vault

Injection

header (X-Vault-Token)

A Vault service token for the customer's own cluster, held in the client's own secret manager. Token issuance is external: an out-of-band deployment process authenticates to a Vault auth method (for example an AppRole login) and stores the resulting service token (an 'hvs.'-prefixed string) under this reference; the pack creates no token and the injector performs no login — it injects the stored value verbatim in the X-Vault-Token header on every call. Vault also accepts the same token as 'Authorization: Bearer <token>'; this pack registers X-Vault-Token only, and a deployment must not store both forms under one reference. Every non-root token has a TTL: prefer renewable service tokens with a short TTL, with renewal owned by the external custody job — an expired token fails closed with a 403. Prefer service tokens over batch tokens, which Vault documents as not revocable. Never store a root token under this reference. Revocation behavior, corrected per the retrieved auth-disable reference: DISABLING an auth method mount (DELETE /sys/auth/:path, the API form of 'vault auth disable') immediately revokes ALL access tokens generated via that mount — Vault's own command documentation states they are immediately revoked and the call blocks until revocation completes. Deleting a ROLE within a mount is a different operation and does not revoke tokens already issued under it: those remain valid until their TTL expires, so TTLs must be short, and the per-token cut-offs are explicit revocation (auth/token/revoke) or revoking a parent token, which revokes its children and their leases. Least privilege: the token's ACL policy should grant exactly the registered operations on the bound mount and paths — read on the concrete MOUNT/data/PATH paths, list and read on MOUNT/metadata/PATH, update on MOUNT/data/PATH and MOUNT/destroy/PATH, delete on MOUNT/data/PATH and MOUNT/metadata/PATH as the enabled capabilities require (the registered soft-delete and metadata-delete operations are HTTP DELETEs and need the delete ACL capability), and update on sys/leases/revoke only if the lease capability is enabled — the revoke endpoint additionally requires sudo authorization on that path, so grant sudo ONLY on sys/leases/revoke when the lease capability is enabled, and nothing more: no other sudo capability, and no wildcard path access, so grant these on the concrete bound paths rather than MOUNT/data/*-style wildcards. No metadata-update permission is needed: this pack registers no metadata write, only metadata list/read and metadata delete. Executor hygiene: the token must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• vault-cluster (api, internal): https://vault-cluster.invalid/v1

The endpoint host 'vault-cluster.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Vault cluster address before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable. MOUNT and PATH in the endpoint paths are placeholders: MOUNT binds to the KV version 2 secrets engine mount path (for example 'secret') and PATH to the secret path; bind both before enabling. This pack registers only KV v2 engine paths — KV v1 mounts use different paths (no data/metadata segments) and are not registered. Tiering rationale: the KV v2 secret-value read sits at the R0 read floor like every read in the library — the confidentiality impact of its response (plaintext passwords, keys, tokens) is carried by the capability description and bounded by policy, not by an above-floor tier; metadata and key-name list reads disclose no values and also sit at the R0 floor. Versioned KV v2 writes are registered as create and update at the R2 floor: a POST creates a new version, and prior versions are retained only up to the mount's configured max_versions — retention-driven permanent removal of the oldest versions is possible, so the pack makes no blanket reversibility claim for writes. Soft deletes, version destroys, metadata deletes and lease revocations are registered at the R3 floor: delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) and Vault's own documentation describes destroy as permanently removing version data and the metadata delete as permanently deleting the key metadata and all version data. Soft delete of the latest version (DELETE on the data path) is technically undoable via the undelete path, but the HTTP verb deletes and the registration makes no reversibility claim. Lease revocation is registered as delete at the R3 floor: per the retrieved leases reference the default behavior QUEUES the revocation (immediate completion only with the optional sync=true body parameter), but once revocation completes the dynamic credential or secret the lease tracks is revoked at the backing system and cannot be un-revoked — treating it as delete follows the pack standard that revoke equivalents are irreversible. Documented exclusions: this pack does not register auth/token/create and auth method login endpoints (token issuance is an external custody process, not a governed capability — see the credential note), /sys/leases/revoke-prefix and /sys/leases/revoke-force (sudo-gated mass revocation the Vault documentation itself describes as potentially very dangerous), /sys/policy and /sys/mounts and /sys/auth administration (cluster configuration, not secret operations), seal/unseal and key-rotation operator endpoints, the transit secrets engine (encrypt/decrypt/sign operations are execute-effect capabilities needing their own review), and cubbyhole access. Vault considers PUT and POST synonyms on write paths; this pack registers the documented verb per operation (POST for writes, PUT for destroy) and does not register the alternates. Enterprise namespaces (the X-Vault-Namespace header) are not registered: bind the token's policy and the substituted paths to a single namespace at install.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developer.hashicorp.com/vault/api-docs/secret/kv/kv-v2 (retrieved 2026-09-21)
• https://developer.hashicorp.com/vault/api-docs/system/leases (retrieved 2026-09-21)
• https://developer.hashicorp.com/vault/api-docs (retrieved 2026-09-21)
• https://developer.hashicorp.com/vault/docs/concepts/tokens (retrieved 2026-09-21)
• https://developer.hashicorp.com/vault/api-docs/system/auth (retrieved 2026-09-21)
• https://developer.hashicorp.com/vault/docs/commands/auth/disable (retrieved 2026-09-21)
• https://developer.hashicorp.com/vault/docs/concepts/lease (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.