HashiCorp Vault package v1.1.0

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: 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, create AND update on MOUNT/data/PATH (according to the reviewed KV v2 reference a write requires the create capability when the key does not yet exist and the update capability when it does) and update on 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.

Sudo permissions: the single-lease revoke endpoint this pack registers carries NO sudo requirement — the sudo-gated lease endpoints are the LIST on sys/leases/lookup/:prefix, sys/leases/revoke-prefix and sys/leases/revoke-force, none of which this pack registers — so the token needs no sudo capability at all, and granting none keeps it below the mass-revocation paths. Grant no wildcard path access: bind every grant to 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.

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.

Approval classification: the KV v2 secret-value read sits at the minimum R0 tier for read like every read in the library; assess confidentiality through data classification and policy; but its data class is an AAES classification judgment, not a provider fact: the registered paths are unrestricted over stored content, and a secrets engine can hold personal credentials and personal data, so the value-touching capabilities (secret read, write, delete, version destroy and the metadata delete, which permanently removes all version data) are classified pii, the strictest applicable handling class; the key-name list read discloses no values, remains internal, and also sits at the minimum R0 tier.

Versioned KV v2 writes are registered as create and update at the minimum R2 tier: 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 minimum R3 tier: delete is one of the designated actions requiring human approval 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) can be restored through the separate undelete path. That provider restoration feature does not remove the R3 approval requirement. Lease revocation is registered as delete at the minimum R3 tier: according to the reviewed 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 requires a new credential to restore access — 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 action 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.