improvement: manage Vault configuration with Crossplane Vault provider

[ixxeL2097]

Context

HashiCorp Vault is used as the secret manager for the genmachine cluster. Its configuration (auth methods, secret engines, policies, roles) is currently managed manually or via ad-hoc scripts. This creates drift risk and makes the Vault setup non-reproducible.

The Crossplane Vault provider (or the community crossplane-contrib/provider-vault) allows managing Vault resources as Kubernetes CRDs, bringing Vault configuration fully into the GitOps workflow.

Goal

Replace manual Vault configuration with Crossplane-managed resources to:

• Declare Vault auth methods, secret engines, policies, and roles as YAML manifests in Git
• Apply Vault configuration changes via ArgoCD sync (same GitOps flow as everything else)
• Make the Vault setup auditable, reviewable in PRs, and reproducible from scratch
• Remove operational dependency on manual vault CLI or Terraform

Proposed scope

Vault resources to manage via Crossplane

• KV v2 secret engine mounts (apps/, github/, etc.)
• Kubernetes auth method + roles (for ESO ClusterSecretStore)
• AppRole auth (if used)
• Policies (read-only per namespace/app)
• PKI engine (if fredcorp-ca is Vault-backed)

Tasks

• Choose provider: upbound/provider-vault vs crossplane-contrib/provider-vault
• Deploy the chosen Vault provider as a Crossplane Provider CRD (add to gitops/manifests/crossplane/)
• Configure ProviderConfig with Vault address and token (via ExternalSecret)
• Migrate existing Vault configuration to CRDs, starting with non-critical engines
• Validate reconciliation loop (CRD → Vault)
• Document the Vault-as-code structure under docs/

References

• https://marketplace.upbound.io/providers/upbound/provider-vault
• https://github.com/crossplane-contrib/provider-vault
• https://developer.hashicorp.com/vault/docs