HashiCorp — BizFirstAI Node Reference

What it does: The HashiCorp node (hashicorp) talks to a tenant-operated HashiCorp Vault server (self-hosted OSS/Enterprise, or HCP Vault Dedicated) over its REST HTTP API. It exposes KV secrets (v1/v2), Vault client-token lifecycle, dynamic-secret lease management, and unauthenticated health/seal-status checks as workflow steps. There is no BizFirst-hosted Vault and no default server address — every operation is pointed at your Vault via the vaultAddress config key.

Folder note: This node lives under the platform's Blockchain ExecutionNodes folder for repo-organization reasons only. HashiCorp's actual product here is Vault (secrets management) — nothing on this node talks to a blockchain, and no Terraform or Consul integration exists in this codebase.

Quick Start

Add a HashiCorp node to your workflow
Set vaultAddress to your Vault server's base URL, e.g. https://vault.internal.example.com:8200
Set authMethod to token or appRole, and credentialID to the matching BizFirst credential record
Set resource to secrets and operation to read
Set mount (e.g. secret) and path to the secret you want
Run the workflow — the node returns the secret's data map

Tip: Every operation shares the same handful of top-level config keys — resource, operation, vaultAddress, authMethod, credentialID — plus a small set of operation-specific fields. Learn the shared pattern once on Input & Output and every operation below follows it. The two system operations skip credentials entirely — see System Operations.

Pages in This Guide

Configuration

vaultAddress, project layout, and dependency registration.

Authentication

Vault token vs. AppRole, credential mapping, and namespaces.

Secrets Operations

KV v1/v2 read, write, delete, undelete, destroy, list, and metadata — 8 operations.

Token Operations

Lookup, renew, and revoke Vault client tokens — 5 operations.

Lease Operations

Renew, revoke, and inspect leases on dynamic secrets — 3 operations.

System Operations

Unauthenticated health and seal-status pre-flight checks — 2 operations.

Input & Output

The shared config-key pattern and how results are shaped.

Error Codes

All 12 HASHICORP_* error codes and what triggers each one.

Examples

Worked workflow patterns using this node.

Troubleshooting

Common issues, sealed vaults, and single-use AppRole gotchas.

Roadmap

Transit encryption, more auth methods, and open decisions.

Core Concepts

Resources

18 action operations across 4 resources. There are no triggers — Vault's HTTP API is entirely pull-based for everything in scope:

secrets — KV v1/v2 secret data: read, write, delete, undelete, destroy, list, readMetadata, updateMetadata
token — Vault client-token lifecycle: lookupSelf, lookupByAccessor, renewSelf, renewByAccessor, revokeByAccessor
lease — leases on dynamic secrets issued by another engine (database/AWS/PKI): renew, revoke, lookup
system — unauthenticated pre-flight checks: health, sealStatus

Bring Your Own Vault

Unlike nodes that call a fixed public API, this node has no default server. Every call carries the tenant's own vaultAddress — self-hosted OSS/Enterprise Vault, or HCP Vault Dedicated. There is deliberately no BizFirst-wide default address in application settings.

Two Auth Methods

Every operation except the two system checks needs authMethod (token or appRole) plus a credentialID pointing at a BizFirst credential record. See Authentication for exactly how each maps to a Vault client token.

Operation Summary

Resource	Operations	Guide Page
`secrets`	`read`, `write`, `delete`, `undelete`, `destroy`, `list`, `readMetadata`, `updateMetadata`	Secrets Operations
`token`	`lookupSelf`, `lookupByAccessor`, `renewSelf`, `renewByAccessor`, `revokeByAccessor`	Token Operations
`lease`	`renew`, `revoke`, `lookup`	Lease Operations
`system`	`health`, `sealStatus`	System Operations