Introduction
HashiCorp Vault is described as a secure digital vault for sensitive information like passwords, API keys, and encryption certificates. It acts as a central location to store, access, and manage these secrets. The utility of Vault is rooted in strong security through encryption of secrets and control of access with different permission levels, which minimizes the risk of unauthorized access and keeps sensitive information safe. Centralized management eliminates scattered secrets and makes control and audit of access easier. Vault can store various secrets from database credentials to cloud API keys and integrates with different tools and platforms already in use. Overall, Vault helps organizations improve security, simplify secret management, and streamline access control for critical information. While Vault has a free open-source version with limited features, most businesses opt for the paid edition with additional functionalities like advanced auditing and disaster recovery.
In the Terraform and Vault context, a demonstration workflow begins with launching one EC2 instance with basic configuration and accessing it. Then the machine is updated and GPG is installed. The command used in the reference material is:
sudo apt update && sudo apt install gpg
The Terraform Vault provider is maintained by the Vault team at HashiCorp. The provider uses the Vault HTTP API to interact with Vault using a series of files called a configuration. This configuration and the provider manage the resources that Terraform creates in Vault. The provider plugin is built with Go and requires Terraform 0.12.x and above. The recommendation is to use the latest stable release whenever possible. Go 1.20 is required to build the provider plugin. The build process involves cloning the repository to $GOPATH/src/github.com/hashicorp/terraform-provider-vault.
mkdir -p $GOPATH/src/github.com/hashicorp; cd $GOPATH/src/github.com/hashicorp
git clone [email protected]:hashicorp/terraform-provider-vault
cd $GOPATH/src/github.com/hashicorp/terraform-provider-vault
make build
Working on the provider requires Go installed on the machine with version 1.20+ and correct setup of GOPATH, as well as adding $GOPATH/bin to $PATH. To compile the provider, run make build.
HashiCorp Vault Core Concepts and Security Model
Vault provides Secrets Management for securely store and control access to tokens, passwords, certificates, API keys, and other sensitive data. Dynamic Secrets generate secrets on the fly, for example database credentials that expire after use. Data Encryption allows encrypt and decrypt data without storing it, using APIs. Access Control provides fine-grained policies to control who can access what. Audit Logs provide full traceability of access and actions taken.
Vault encrypts secrets and controls access with different permission levels. This minimizes risk of unauthorized access. Centralized management keeps everything in one place, making it easier to control and audit who can access what. The system supports various secret types from database credentials to cloud API keys.
Integration with tools and platforms is a core capability. The provider for Terraform enables Infrastructure as Code management of Vault resources.
Installing and Configuring HashiCorp Vault on Ubuntu 24.04
HashiCorp Vault is an open-source tool designed for managing secrets and protecting sensitive data in dynamic infrastructure environments. It is commonly used in DevOps, cloud-native, and microservices architectures.
The installation process on Ubuntu 24.04 begins with system update.
sudo apt-get update && sudo apt-get upgrade -y
The HashiCorp apt repository is added using GPG key import.
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vault
Enable, start and check the Vault services.
systemctl daemon-reload
systemctl start vault
systemctl enable vault
systemctl status vault
Access is via https://127.0.0.1:8200/. During initial setup, Key shares is where you would enter the total number of pieces you want to split the root key into.
The reference material notes that in a demo scenario, a duplicate session of the machine is created and a command is run on it. Because HashiCorp Vault does not support creation of users in the UI, user creation is performed on the console.
Vault Policy and AppRole Configuration for Terraform
Before creating a role, a policy for that role must be created. This policy enables Terraform to access the 'kv' and 'secret' folders in Vault. The policy write command used is:
vault policy write terraform - <<EOF
path "*" {
capabilities = ["list", "read"]
}
path "secrets/data/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "kv/data/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "secret/data/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "auth/token/create" {
capabilities = ["create", "read", "update", "list"]
}
EOF
Now a role is created with specific TTL and usage limits.
vault write auth/approle/role/terraform \
secret_id_ttl=10m \
token_num_uses=10 \
token_ttl=20m \
token_max_ttl=30m \
secret_id_num_uses=40 \
token_policies=terraform
Similar to AWS, in Vault there is a Role ID and Secret ID. This is sensitive information so it should not be shared with anyone.
vault read auth/approle/role/terraform/role-id
vault write -f auth/approle/role/terraform/secret-id
The AppRole method provides machine-to-machine authentication for Terraform workloads. The secretidttl, tokennumuses, tokenttl, tokenmaxttl, and secretidnumuses parameters control the lifetime and reuse limits of credentials.
Terraform Provider for Vault Architecture
The Vault provider for Terraform uses the Vault HTTP API to interact with Vault using a series of files called a configuration. This configuration and the provider manage the resources that Terraform creates in Vault.
The provider plugin is maintained by the Vault team at HashiCorp. The recommendation is to avoid placing secrets in Terraform config or state file wherever possible, and if placed there, steps must be taken to reduce and manage risk. A practical guide exists on how to do this with open-source versions in Best Practices for Using HashiCorp Terraform with HashiCorp Vault. A webinar walks through how to protect secrets when using Terraform with Vault. Additional security measures are available in paid Terraform versions as well.
Terraform version requirements are 0.12.x and above. The latest stable release is recommended whenever possible. Go 1.20 is required to build the provider plugin.
The repository clone path is $GOPATH/src/github.com/hashicorp/terraform-provider-vault.
Development Server and Authentication Workflow Example
A tutorial scenario uses Oliver and the operations team managing Vault at HashiCups. Part of Oliver's job is to create logins and passwords for developers at HashiCups to log in to Vault.
Danielle and the development teams need to log in to Vault to create secrets used by services at HashiCups. Oliver will enable the userpass auth method, create a user, set a password, and create and attach a policy to the user. The development team needs a secrets engine, which Oliver will create. Danielle will then log into Vault using the userpass auth method, and create a secret.
A new standard at HashiCups requires teams to manage infrastructure with Terraform. Danielle and Oliver are also starting to use Vault, and want to use the advantages of Infrastructure as Code to manage Vault.
To complete this tutorial, the following is required:
Open a terminal and start a Vault dev server with the literal string root as the root token value, and enable TLS.
vault server -dev -dev-root-token-id root -dev-tls
The dev server listens on the loopback interface at 127.0.0.1 on TCP port 8200 with TLS enabled.
This example illustrates the authentication flow and secret creation flow that Terraform can codify.
Terraform Cloud Agent Integration with Vault
The Terraform Cloud agent should be able to use private non-public networking leveraging HashiCorp Virtual Network, HVN. In the example shown, Terraform is connected to Vault using the Terraform Cloud agent when Terraform and Vault are on different networks. While this example shows HCP Terraform and HCP Vault Dedicated, the same pattern can be used for Terraform Enterprise and Vault Enterprise in different networks.
The Terraform operation guides include recommended people and process patterns. It is recommended that the platform team admin is responsible for the following:
- Ensure that the integration between HCP Terraform and HCP Vault is established.
- Establish an appropriate mapping between the Terraform projects, workspaces and Vault namespaces keeping RBAC and scalability as priorities.
- Ensure that the appropriate Terraform workspaces are assigned the correct variable sets with Vault static secrets or/and integrated with the appropriate Vault namespaces and secret engines for dynamic credentials.
- Ensure documentation is in a centralized location for the application team regarding this integration.
- Set up periodic collaboration meetings with the cross-functional teams to ensure that the integration's objectives are being met.
The first step of integrating Terraform with Vault is to authenticate Terraform to Vault.
The integration pattern supports private networking and separation of concerns between platform and application teams.
Provider Release History and Breaking Changes
Release information for the Terraform provider for Vault is published.
The release v5.10.1 was published on June 26, 2026.
BREAKING CHANGES:
Reverted the 5.10.0 support for pkcs12bundle and jksbundle formats in formats in vaultpkisecretbackendcert, vaultpkisecretbackendrootcert, vaultpkisecretbackendrootsignintermediate, and vaultpkisecretbackend_sign that forced resource recreation. Configurations using these formats or their related arguments are no longer supported.
The release v5.10.0 was published on June 23, 2026.
FEATURES:
New Resource:
vaultconfiguidefaultauth
Manages UI default authentication configuration for the Vault GUI login form. Controls which authentication methods are displayed by default and as backup options for specific namespaces. Supports inheritance control for child namespaces. Enterprise-only feature requiring Vault 1.20.0+.
vaultconfigcontrol_group
Added initial implementation for vaultconfigcontrol_group resource in sys/config/control-group.
New Resource:
vaultconfigui_header
Manages custom HTTP headers for the Vault UI. Supports security headers, CSP, HSTS, X-Frame-Options, CORS configuration, and custom organizational headers. Requires Vault 1.16.0+.
New Resource:
Add support for RADIUS auth backend:
vaultradiusauthbackend and vaultradiusauthbackenduser resource and vaultradiusauthlogin ephemeral resource.
New Resource:
vaultactivationflags for managing Vault features that are gated by one-time flags.
These changes show ongoing expansion of provider capabilities for UI configuration, control groups, security headers, RADIUS authentication, and feature flags.
Practical Integration Workflow
The demo workflow starts with launching one EC2 instance with basic configuration and access it. Then the machine is updated and GPG is installed.
sudo apt update && sudo apt install gpg
The workflow continues with Vault policy creation and AppRole role creation as detailed above. The sensitive Role ID and Secret ID are retrieved and protected.
The Terraform configuration uses the Vault provider to manage resources inside Vault. Secrets are stored in kv and secret engines. Access is controlled via policies attached to AppRole or userpass identities.
Dynamic secrets can be generated on demand with short TTLs, reducing exposure window. Audit logs provide traceability of who accessed what and when.
Security Best Practices
Avoid placing secrets in Terraform config or state file wherever possible. If placed there, risk reduction measures must be applied. The Best Practices guide covers open-source methods. Paid Terraform versions offer additional security measures.
Fine-grained policies limit capabilities to list, read, create, update, delete as needed per path. Token TTLs and max TTLs limit credential lifetime. Token num uses and secretidnum_uses limit reuse.
AppRole credentials should be treated as sensitive and not shared. Role ID and Secret ID must be protected.
Centralized management ensures all secrets are in one location with consistent audit logging.
Conclusion
Terraform HashiCorp Vault integration provides a comprehensive mechanism for managing secrets as code while maintaining strong security posture. Vault offers strong security through encryption and access control, centralized management, dynamic secrets, data encryption, and audit logs. Installation on Ubuntu 24.04 uses the official HashiCorp apt repository with GPG verification. Provider builds require Go 1.20+ and Terraform 0.12+. Authentication patterns include userpass for developers and AppRole for machine workloads. Policies control access to kv and secret paths. Terraform Cloud agent integration enables private networking via HVN and separation of platform and application responsibilities. Provider releases continue to add UI configuration, control groups, security headers, RADIUS backend, and feature flag management. The integration enables Infrastructure as Code management of Vault while minimizing secret exposure through short-lived dynamic credentials and auditable access.