Skip to content

How Each Tool Consumes Vault

Every consumer authenticates against the same devhome KV mount (see Vault Overview), but each one reads secrets through a different mechanism — worth knowing so you look in the right place when one of them can't find a credential.

Terraform

data "vault_kv_secret_v2" data sources, resolved at plan/apply time via the vault provider:

data "vault_kv_secret_v2" "vmware" {
  mount = "devhome"
  name  = "vmware"
}
# ... data.vault_kv_secret_v2.vmware.data["vsphere_username"]

Requires VAULT_ADDR/VAULT_TOKEN in the environment the terraform command runs in — sourced from .vault_env before any plan/apply (see Developer Setup).

Ansible

The community.hashi_vault.vault_kv2_get lookup plugin, resolved once per secret in group_vars/all.yml and reused throughout:

_vmware_secret: "{{ lookup('community.hashi_vault.vault_kv2_get', 'vmware', engine_mount_point='devhome').secret }}"

Downstream vars (e.g. kubeconfig_base_dir) then reference _vmware_secret.<key> rather than calling the lookup repeatedly. Same VAULT_ADDR/VAULT_TOKEN environment requirement as Terraform — this is why every ADO pipeline step that runs Ansible sources .vault_env first.

Packer

Build credentials (devhome/packer in Vault) are provisioned into Terraform-managed state via terraform/vault/packer.tf, keeping Packer on the same "nothing hardcoded in a vars file" rule as everything else — a .pkrvars.hcl should never contain a literal credential.

Local shell / ADO self-hosted agent

Anything invoked directly — a one-off curl against Vault's REST API, a PowerShell script (bootstrap_esxi.ps1, the supervisor destroy scripts), or a manual debugging session — sources .vault_env for VAULT_ADDR/VAULT_TOKEN and then either:

  • calls the REST API directly: 
    curl -sk -H "X-Vault-Token: $VAULT_TOKEN" "$VAULT_ADDR/v1/devhome/data/vmware"
  • or, from PowerShell, Invoke-RestMethod against the same endpoint (the pattern used throughout bootstrap_esxi.ps1 and the Tanzu Supervisor destroy scripts).

The self-hosted ADO agent (see Self-Hosted Azure DevOps Agent) uses this same raw-REST pattern for any pipeline step that isn't already Terraform or Ansible.

The one path that doesn't exist

devhome/vcenter — a couple of older scripts referenced this path with username/ password fields. It was never real post-reorg; the actual vCenter/ESXi credentials live under devhome/vmware as vsphere_username/vsphere_password. If a script gets an empty {"errors":[]} response from Vault, this is the first thing to check.