.png)
HashiCorp Vault Integration Guide
Integrate HashiCorp Vault with enterprise systems through its HTTP API, authentication methods, secrets engines, leases, and policy-controlled workflows.
HashiCorp Vault integration options at a glance
HashiCorp Vault's primary integration surface is its versioned HTTP API for authentication, KV secrets, dynamic credentials, leases, policies, mounts, health checks, and Transit operations. Requests can use client tokens or machine-oriented authentication methods such as AppRole, Kubernetes, JWT/OIDC, AWS, Azure, GCP, or TLS certificates. Vault does not document general-purpose GraphQL, SOAP, webhook, callback, or file APIs. Martini can consume the Vault REST API through workflows, map KV v1 or KV v2 responses, retrieve dynamic database credentials, renew or revoke leases, and expose controlled APIs for authorized callers. Scheduled workflows can poll selected paths or external audit pipelines when change-driven processing is required.
| Integration point | Supported by HashiCorp Vault? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Vault's versioned HTTP API supports authentication, KV secret reads and writes, dynamic credentials, lease operations, policies, mounts, health checks, audit configuration, and Transit encryption. | Martini can consume the Vault REST API from workflows, generate reusable API-facing integration assets, map responses, apply business rules, and handle status-specific errors. |
| Authentication | Yes | Vault supports client tokens and authentication methods including AppRole, Kubernetes, JWT/OIDC, AWS, Azure, GCP, TLS certificates, LDAP, Userpass, and GitHub. | Martini can protect connection configuration and invoke the selected Vault authentication flow, then use the resulting token within controlled workflow scopes. |
| KV secrets | Yes | The KV secrets engine stores static key-value data; KV version 2 adds versioning, metadata, soft deletion, and check-and-set behavior. | Martini can read and write KV values, explicitly map KV v1 or KV v2 response structures, validate payloads, and apply idempotency or version checks. |
| Database secrets engine | Yes | Vault can generate, renew, and revoke dynamic database credentials for supported database systems. It is not a general SQL analytics interface. | Martini can request dynamic credentials, use them for a controlled database workflow, and coordinate lease renewal or revocation with downstream error handling. |
| Leases and tokens | Yes | Tokens and dynamic credentials can have TTLs, renewal behavior, policies, parent-child relationships, and revocation requirements. | Martini can track expiration metadata, branch on authentication or lease failures, renew when appropriate, and avoid assuming credentials remain valid for the full workflow. |
| Bulk or batch APIs | Limited | Vault includes batch-related concepts such as batch tokens, but no general-purpose bulk secret synchronization API is documented. | Martini can use bounded requests, controlled path listing, pagination where supported, retry-safe processing, and scheduled orchestration instead of assuming bulk export semantics. |
| Database access | Limited | The Database secrets engine manages dynamic database credential lifecycle; Vault does not provide general database queries, reporting, or analytics access. | Martini can consume the generated credential and connect to a separate supported database endpoint for the actual SQL operation. |
| Webhooks and outbound callbacks | No | Vault documents audit devices and API operations but does not document general-purpose outbound webhooks for secret, policy, or lease changes. | Martini can use scheduled polling, an external audit or monitoring pipeline, or an explicit invocation process when change-driven behavior is required. |
| GraphQL and SOAP APIs | No | No official Vault GraphQL or SOAP interface is documented; the HTTP API is the principal integration boundary. | Martini can consume the documented REST API rather than relying on unsupported GraphQL or SOAP endpoints. |
How HashiCorp Vault exposes data and business events
HashiCorp Vault REST APIs
Vault's versioned HTTP API is the primary integration mechanism for authentication, secret storage and retrieval, dynamic credential generation, lease management, policy operations, health checks, and Transit operations. Calls are organized around mounted paths and the selected engine or auth method.
Martini implementation pattern
Martini implementation pattern: Martini workflows authenticate to Vault, call the required endpoint, validate the status and response shape, map the result into a canonical model, and invoke the downstream application or database. Mount paths, namespaces, engine versions, and environment-specific endpoints remain configurable rather than being embedded throughout mappings.
Implementation sequence
Vault authentication methods
Vault supports token authentication and multiple machine or workload authentication methods, including AppRole, Kubernetes, JWT/OIDC, AWS, Azure, GCP, and TLS certificate authentication. Authorization is then enforced through policies, namespaces, token properties, and path capabilities.
Martini implementation pattern
Martini implementation pattern: a workflow selects an authentication method appropriate to its runtime environment, sends only the required identity material, extracts the resulting token, and uses it for narrowly scoped API calls. Authentication failures, policy denials, token expiration, and namespace mismatches are handled as distinct outcomes.
Implementation sequence
KV and dynamic database credentials
KV engines provide static key-value secrets, while the Database secrets engine generates and manages short-lived database credentials. KV v2 adds versioning, metadata, soft deletion, and check-and-set behavior; dynamic credentials are associated with leases.
Martini implementation pattern
Martini implementation pattern: Martini retrieves a KV value or requests a dynamic credential, validates the expected engine version and response wrapper, uses the value only for the required operation, and coordinates lease handling. Database queries occur against the database service, not through Vault's API.
Implementation sequence
Scheduled Vault synchronization
Vault is not documented as providing general-purpose outbound webhooks or callbacks for secret changes, rotations, policy updates, or lease events. Change-aware integrations therefore use scheduled polling, an external audit or monitoring pipeline, or an explicit orchestration request.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a bounded workflow that lists or reads selected Vault paths, compares relevant metadata or versions with a checkpoint, and processes only required changes. The workflow uses controlled concurrency, retry backoff, and checkpoint persistence rather than assuming a bulk export or event stream.
Implementation sequence
Common HashiCorp Vault integration patterns
Pattern 1: Retrieve application secrets at runtime
When to use this pattern
Use this pattern when an application or scheduled process needs a database password, API key, or service configuration value without embedding a long-lived secret in application code or Martini workflow definitions.
Integration direction
Example Mapping
| HashiCorp Vault Field | Canonical Field | Target Field |
|---|---|---|
| Vault secret path | secretReference | Configured downstream credential reference |
| KV data | credentialValue | Authorization or connection credential |
| KV metadata.version | secretVersion | Checkpoint or audit context |
| Vault namespace | environmentScope | Selected downstream environment |
Martini implementation pattern
Martini receives an authorized request, authenticates to Vault, reads the configured KV path, validates the expected KV version and fields, and uses the value in a downstream call. Business rules restrict which paths may be requested, while error handling distinguishes missing paths and policy failures from transient Vault availability problems. Secret values are excluded from logs and external error responses.
Martini capabilities used
- Workflows
- API consumption
- Secure configuration
- Data mapping
- Business rules
- Error handling
Pattern 2: Generate dynamic database credentials
When to use this pattern
Use this pattern when a workflow needs temporary database access and static database passwords should not be stored in application configuration or integration code.
Integration direction
Example Mapping
| HashiCorp Vault Field | Canonical Field | Target Field |
|---|---|---|
| Vault database role | credentialRole | Database access profile |
| lease_id | credentialLeaseId | Lease tracking store |
| lease_duration | credentialLifetime | Workflow expiration policy |
| data.username | databaseUsername | Database connection username |
Martini implementation pattern
Martini calls the Database secrets engine, validates the returned username, password, lease identifier, and duration, and uses the credentials for a bounded SQL operation. The workflow applies business rules for allowed roles and execution time, retries only transient failures, and renews or revokes the lease when the process requires it.
Martini capabilities used
- Workflows
- API consumption
- Database connectivity
- Data mapping
- Business rules
- Retry and error handling
Pattern 3: Coordinate controlled secret rotation
When to use this pattern
Use this pattern when a scheduled process must validate or rotate Vault-managed credentials and update an external configuration or service endpoint. It is appropriate where no direct Vault webhook is available.
Integration direction
Example Mapping
| HashiCorp Vault Field | Canonical Field | Target Field |
|---|---|---|
| Vault secret path | rotationTarget | Configuration resource identifier |
| KV v2 version | sourceVersion | Expected configuration version |
| rotated credential | newCredential | External service credential |
| lease or token expiry | validUntil | Credential activation policy |
Martini implementation pattern
A scheduled Martini workflow reads the configured Vault value or invokes the relevant Vault operation, validates the result, and updates the external configuration endpoint only when business rules permit. Check-and-set or version-aware logic helps prevent overwriting a newer value. Failures are retried selectively and the last successful checkpoint is retained.
Martini capabilities used
- Scheduling
- Workflows
- API consumption
- Data mapping
- Business rules
- Checkpointing
- Error handling
Pattern 4: Expose a controlled secret retrieval API
When to use this pattern
Use this pattern when applications need a narrowly defined secret or credential operation but should not receive direct access to Vault paths, policies, administrative endpoints, or broad Vault tokens.
Integration direction
Example Mapping
| HashiCorp Vault Field | Canonical Field | Target Field |
|---|---|---|
| application request | authorizedSecretRequest | Vault path and operation |
| caller identity | requestPrincipal | Business authorization rule |
| Vault response data | approvedSecretValue | Filtered API response |
| Vault error status | integrationError | Safe consumer error response |
Martini implementation pattern
Martini exposes a REST API that validates the caller, permits only configured operations and paths, invokes Vault with a separately scoped credential, and returns only the required value or status. The workflow masks sensitive errors, applies authorization rules before the Vault call, and records operational metadata without recording secret content.
Martini capabilities used
- API exposure
- Workflows
- Authentication and authorization
- API consumption
- Data mapping
- Business rules
- Error handling
Applications commonly integrated with HashiCorp Vault
HashiCorp Vault is commonly positioned between workloads, delivery platforms, cloud providers, and enterprise services that need controlled access to secrets or short-lived credentials. Martini can orchestrate these interactions through Vault's APIs without exposing Vault paths or administrative operations to every consuming application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Kubernetes | Authenticate workloads to Vault and provide application secrets or dynamic credentials without embedding long-lived tokens in containers. | Kubernetes → Martini → HashiCorp Vault | Martini receives a workload or deployment request, authenticates to Vault using an approved workload identity or configured token, retrieves narrowly scoped secrets, and returns or uses only the required values while suppressing sensitive data in logs. |
| Amazon Web Services | Authenticate AWS workloads and generate or manage AWS credentials through Vault's AWS authentication and secrets capabilities. | Amazon Web Services → Martini → HashiCorp Vault | A Martini workflow invokes the appropriate Vault authentication and secrets-engine endpoints, validates the returned credential metadata, and uses the short-lived result in a downstream AWS operation with lease-aware cleanup. |
| Microsoft Azure | Authenticate Azure-hosted workloads and manage Azure-related credentials through Vault. | Microsoft Azure → Martini → HashiCorp Vault | Martini accepts an Azure workload request, authenticates to Vault using the selected Azure-compatible method, maps the response into the required service configuration, and applies authorization and expiration rules before use. |
| Google Cloud | Authenticate Google Cloud workloads and issue or manage Google Cloud service-account credentials. | Google Cloud → Martini → HashiCorp Vault | Martini calls Vault's authentication and relevant secrets-engine endpoints, transforms the credential response into the target request model, and handles lease expiration or revocation through workflow logic. |
| Terraform | Supply provider credentials and sensitive values to Terraform runs while retaining centralized Vault control. | HashiCorp Vault → Martini → Terraform | A Martini workflow retrieves an approved Vault secret or dynamic credential, validates its scope and lifetime, and passes only the required values to a Terraform execution or configuration endpoint without persisting secret content. |
| GitHub Actions | Provide short-lived credentials to CI/CD jobs instead of storing long-lived repository secrets. | GitHub Actions → Martini → HashiCorp Vault | Martini coordinates a job request or callback flow, invokes Vault through a suitable JWT/OIDC or token-based method, applies policy checks, and returns a narrowly scoped credential with explicit expiration handling. |
| Datadog | Supply API keys or integration credentials from Vault to monitoring configuration or deployment workflows. | HashiCorp Vault → Martini → Datadog | Martini reads the required Vault value, validates the target environment and credential scope, maps it to a Datadog configuration request, and prevents the secret from appearing in workflow logs or error responses. |
| Jenkins | Provide build and deployment jobs with short-lived credentials for cloud accounts, databases, and APIs. | Jenkins → Martini → HashiCorp Vault | A Martini API or scheduled workflow receives the job context, authenticates to Vault, retrieves the permitted credential, and returns a controlled response while handling token and lease renewal requirements. |
How to build a HashiCorp Vault integration in Martini
Objective
Establish the Vault endpoint, namespace, TLS behavior, and environment-specific authentication configuration without embedding sensitive values in workflow definitions.
Instructions in Martini
- Configure the Vault HTTPS endpoint and namespace where required
- Select AppRole, token, workload identity, certificate, or another approved authentication method
- Store sensitive connection material using protected Martini configuration
- Validate certificate trust and avoid disabling verification as a workaround
Objective
Select an API request, scheduled trigger, or explicit orchestration event based on whether the process is request-driven or must poll Vault or an external audit pipeline.
Instructions in Martini
- Use an API trigger for controlled application requests
- Use a scheduler for polling or rotation workflows
- Do not assume Vault provides general-purpose outbound webhooks
- Define a bounded polling scope and checkpoint strategy
Objective
Authenticate to Vault and retrieve the required KV value, dynamic credential, policy information, lease, or system response through the documented HTTP API.
Instructions in Martini
- Call the appropriate authentication endpoint
- Invoke the mounted secrets-engine or system endpoint
- Handle KV v1 and KV v2 response shapes explicitly
- Validate status codes and required response fields
Objective
Coordinate Vault calls with downstream API, database, or configuration operations while keeping token and secret lifecycles within the workflow's execution boundaries.
Instructions in Martini
- Sequence authentication, retrieval, validation, and downstream calls
- Use reusable workflow logic for common Vault operations
- Track lease identifiers and expiration metadata when applicable
- Prevent secret values from entering logs or external errors
Objective
Convert Vault-specific response wrappers, metadata, credentials, and lease details into a canonical model required by the target system.
Instructions in Martini
- Map KV v1 or KV v2 fields deliberately
- Normalize token and lease metadata
- Transform database credential responses into connection parameters
- Apply JSON validation and field-level filtering
Objective
Enforce least-privilege path access, allowed operations, environment boundaries, credential lifetimes, and version-aware write behavior before changing data or returning a result.
Instructions in Martini
- Reject unauthorized paths and unsupported operations
- Use check-and-set or version checks for sensitive KV writes
- Treat 401, 403, and 404 responses according to their meaning
- Allow retries only for appropriate transient conditions
Common HashiCorp Vault data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Secrets engines | Provide pluggable storage or generation capabilities such as KV, Database, AWS, Azure, and PKI secrets. | Martini workflows, Kubernetes, cloud workloads, databases, CI/CD platforms | Martini invokes the relevant mounted-engine endpoints, stores mount configuration by environment, and applies response validation and error handling. |
| KV secrets | Store static key-value data such as passwords, API keys, and service configuration; KV v2 also provides versions and metadata. | Applications, APIs, databases, Terraform, Jenkins, GitHub Actions | Martini maps KV v1 and KV v2 response shapes explicitly, protects values from logs, and uses check-and-set or version-aware writes when required. |
| Auth methods | Authenticate users, workloads, or machine-to-machine integrations through mounted methods such as AppRole, Kubernetes, JWT, AWS, Azure, or GCP. | Kubernetes, cloud workloads, Martini APIs, CI/CD platforms | Martini invokes the selected login endpoint, extracts the resulting token, and applies environment-specific namespace, TTL, and renewal handling. |
| Policies | Define path-specific capabilities such as read, create, update, delete, list, and sudo. | Vault namespaces, workflows, applications, operations teams | Martini uses least-privilege roles and treats 403 responses as authorization failures rather than retryable transport errors. |
| Tokens | Authenticate API requests and carry policies, TTLs, renewal behavior, identity, and namespace scope. | Martini workflows, applications, automation jobs | Martini protects tokens as sensitive configuration, tracks expiry, renews or re-authenticates when appropriate, and avoids exposing them in logs or responses. |
| Leases | Represent time-bound access associated with dynamic secrets and renewable or revocable credentials. | Database clients, cloud services, deployment workflows, applications | Martini records lease metadata needed for the workflow, handles renewal or revocation, and prevents expired credentials from being reused. |
Authentication and security considerations
Authentication and authorization
Vault supports client tokens and multiple authentication methods, including AppRole, Kubernetes, JWT/OIDC, AWS, Azure, GCP, TLS certificates, LDAP, Userpass, and GitHub. Select the method that matches Martini's runtime identity and organizational security policy.
Least privilege
Use dedicated roles and narrowly scoped policies for each integration. Avoid root or administrative tokens, restrict paths and capabilities, and configure namespaces explicitly for Vault Enterprise deployments.
Protect sensitive values
Store Vault connection material in protected Martini configuration. Do not write tokens, returned secrets, dynamic credentials, or sensitive request bodies to workflow logs or external error responses.
TLS and wrapping
Use HTTPS with deliberate certificate validation and configure private certificate authorities or client certificates where required. Response wrapping can transfer a short-lived, single-use token without exposing the underlying secret directly.
Operational considerations for HashiCorp Vault integrations
Token and lease lifecycle
Tokens and dynamic credentials can expire, renew, or be revoked. Workflows should track TTL and lease metadata and re-authenticate or renew only when appropriate.
KV versions and idempotency
KV v1 and KV v2 have different paths and response structures. KV v2 versioning and check-and-set behavior should be reflected in mappings and duplicate-processing rules.
Pagination and bounded requests
Vault list operations return paths rather than a complete recursive export. Use bounded traversal, controlled concurrency, checkpoints, and retry backoff for larger synchronization processes.
Availability and errors
Handle 401, 403, 404, 412, 429, 500, and 503 responses according to their meaning. Consider sealed, standby, redirect, proxy, and load-balancing behavior in the deployment.
Testing and monitoring
Test authentication, namespace selection, policy boundaries, KV engine versions, lease expiration, secret masking, and transient failures in non-production environments. Monitor workflow outcomes without capturing secret values.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Martini coordinates Vault authentication, secret retrieval, dynamic credential use, downstream API or database operations, validation, and error handling in an explicit workflow.
Reusable integration logic
Common Vault operations can be organized into reusable workflows and APIs, reducing duplicated authentication, mapping, lease, and masking logic across applications.
Controlled API exposure
Martini can expose an application-specific API that validates callers and restricts allowed Vault paths and operations, instead of exposing broad Vault access directly to every consumer.
Operational reliability
Scheduled execution, business rules, bounded retries, checkpoints, environment-specific configuration, and monitoring provide a maintainable alternative to isolated scripts and fragile point-to-point calls.
Frequently asked questions
HashiCorp Vault can be integrated primarily through its versioned HTTP API. Enterprise workflows can authenticate with tokens, AppRole, Kubernetes, JWT/OIDC, cloud identity, certificates, or other supported methods; read and write KV secrets; obtain dynamic database or cloud credentials; manage leases and policies; and perform health or Transit operations. Vault does not document general-purpose GraphQL, SOAP, or outbound webhook APIs.
Yes. Martini can integrate with HashiCorp Vault by consuming its REST API from workflows, authenticating through an approved Vault method, retrieving KV or dynamic secrets, handling tokens and leases, and exposing controlled APIs for authorized callers. No native Martini Vault connector is verified in the supplied documentation.
No. A dedicated HashiCorp Vault connector is not required. Martini can use Vault's confirmed native integration mechanisms, including its HTTP API, authentication methods, KV and Database secrets engines, token handling, leases, and policy-controlled paths.
Lonti does not charge an additional per-connector or per-vendor fee to integrate HashiCorp Vault. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from HashiCorp, infrastructure providers, databases, cloud platforms, or other third-party systems depending on subscriptions, usage, and deployment choices.
The documented REST API is the primary method for Martini integrations. AppRole is commonly suitable for machine-to-machine access, while Kubernetes, AWS, Azure, GCP, JWT/OIDC, TLS certificate, or another method may be more appropriate when Martini runs in a corresponding environment. The choice should follow deployment architecture, policy, network, and token-lifecycle requirements.
Vault is not documented here as providing general-purpose outbound webhooks or callbacks for secret changes, rotations, policies, or leases. Martini can instead use scheduled polling, an external audit or monitoring pipeline, or an explicit rotation workflow with checkpoints and bounded retries.
Martini can retrieve selected paths or dynamic credentials, map Vault-specific response wrappers into a canonical model, apply validation and business rules, and write results to downstream APIs or databases. Synchronization should account for KV v1 and v2 differences, nested path listing, versions, checkpoints, leases, pagination where supported, and idempotent or check-and-set writes.
Workflows should distinguish authentication failures, policy denials, missing paths, check-and-set conflicts, rate-related responses, and service availability errors. Authentication and authorization failures generally fail fast, while transient conditions can use bounded retries with backoff. KV v2 writes should account for version creation and check-and-set semantics so repeated processing does not unintentionally overwrite newer data or create unwanted versions.
Related Martini documentation
Workflows
Data handling
Integrate HashiCorp Vault with Martini
Use Martini to build secure, maintainable workflows around HashiCorp Vault's APIs, authentication methods, secrets engines, leases, and policy-controlled operations.