Skip to content

Terraform Providers

Nearly every provider below authenticates from Vault-sourced data (data.vault_kv_secret_v2), never a .tfvars literal — see Vault Overview for the exact secret paths. Most are declared once in terraform/vsphere/compute/provider.tf; terraform/azure and terraform/vault each own their own smaller provider.tf.

Core infrastructure

  • vmware/vsphere (2.16.1) — terraform/vsphere/compute/provider.tf (also terraform/vsphere/base, terraform/vsphere/supervisor). Configured with vCenter credentials pulled from Vault (vsphere_username/vsphere_password/vsphere_server under devhome/vmware). Builds and manages VMs, clusters, and datastores — the backbone provider for the whole on-prem stack; see Compute & Storage.
  • hashicorp/vault (~> 4.0) — declared in every stack (azure, vsphere/compute, vsphere/base, vsphere/supervisor, vault itself). Everywhere else it's just the secrets source (data.vault_kv_secret_v2); in terraform/vault/provider.tf it's configured directly against https://vault.devhome.cloud:8200 via a VAULT_TOKEN env var, since that stack manages Vault's own policies/auth backends rather than reading secrets from it.
  • hashicorp/azurerm (4.0.1) — terraform/azure/provider.tf. Authenticated from Vault-stored arm_* secrets (service principal credentials); manages the Azure hub resources described in Cloud: Azure.

Kubernetes / GitOps

terraform/vsphere/compute/provider.tf declares aliased instances of several providers, one per cluster, since the same stack manages resources across dke-mgmt, dke, dkes, and rke2 simultaneously — worth knowing before adding a new cluster, since a new alias is usually needed alongside it (see Bootstrapping a New Cluster):

  • gavinbunney/kubectl (>=1.9.1) — default plus aliased instances (dke, dkes), each pointing at a different kubeconfig, used to apply raw Kubernetes manifests that don't have a clean native Terraform resource.
  • hashicorp/kubernetes (>=2.36.0) — default plus aliased instances (dke_mgmt, dke, dkes, rke2) for managing Kubernetes objects natively across every cluster.
  • hashicorp/helm (~> 3.0.2) — default instance plus a dke_mgmt-aliased one, for Helm chart deployment (mostly onto the management cluster).
  • rancher/rancher2 (8.0.0) — two instances: a bootstrap-aliased one used only for rancher2_bootstrap.admin during initial setup, and the main instance authenticated with the token that bootstrap produces.
  • argoproj-labs/argocd (7.10.1) — configured from Vault argocd_* secrets to manage ArgoCD Applications/AppProjects declaratively — see ArgoCD.

Pipelines & utility

  • microsoft/azuredevops (1.11.2) — configured from Vault azuredevops_* secrets (org URL + PAT); manages the Azure DevOps resources described in Pipelines.
  • hashicorp/cloudinit (>=2.3.0) — generates cloud-init user-data, paired with the templates/userdata.yaml/metadata.yaml templates used when cloning VMs.
  • hashicorp/random (3.4.3), hashicorp/local (~> 2.4), hashicorp/null (~> 3.2), hashicorp/external (~> 2.3) — utility providers with no external API of their own: random IDs/passwords, local file rendering, null_resource/trigger-based provisioners (the pattern the Ansible playbook invocations run through — see Playbook Reference), and shelling out to external data sources.

State backends

terraform/vault uses backend "local", pointing at a path under /mnt/backup/config/terraform/... on TrueNAS shared storage rather than a remote backend — consistent with this being a single-operator homelab, not a team needing locking/collaboration guarantees. terraform/vsphere/{base,compute,supervisor} each keep their own local terraform.tfstate in-directory.