Will Anderson
246368c132
Legion is offline. Vault needs a GCP-native home. This commit provisions a 3-node Vault HA cluster on GCE e2-small VMs (us-central1 a/b/c) backed by Raft consensus with GCP KMS auto-unseal already in place. - vault-nodes.tf: 3 VMs with separate pd-ssd data disks (prevent_destroy), IAP-only SSH firewall, Raft peer firewall (8201), global HTTPS LB for vault.neuralplatform.ai with Google-managed cert, HTTP health checks against /v1/sys/health - vault/startup.sh: idempotent boot script — installs Vault from HashiCorp APT repo, mounts/formats the data disk, writes Raft config with dynamic retry_join peers resolved via gcloud metadata, starts vault.service - vault-auth-gcp.tf: GCP Secret Manager secret for init script; outputs the service account emails needed for GCP auth roles - vault/configure-vault-auth.sh: post-init script to enable gcp auth method, write marketing-policy and soma-policy, bind roles to Cloud Run service account identities After apply: set vault_lb_ip output as A record for vault.neuralplatform.ai in Cloudflare, then run vault operator init on vault-node-1 to bootstrap.
49 lines
2.0 KiB
Terraform
49 lines
2.0 KiB
Terraform
# ── Vault GCP IAM Auth Method — GCP IAM for Cloud Run services ───────────────
|
|
#
|
|
# This file defines the GCP Secret Manager secret that holds the Vault GCP
|
|
# auth configuration script, and the Vault policies for each service identity.
|
|
#
|
|
# IMPORTANT: The Vault Terraform provider is NOT configured in this workspace.
|
|
# The actual Vault auth method configuration is performed by running:
|
|
#
|
|
# servers/gcp/vault/configure-vault-auth.sh
|
|
#
|
|
# That script uses the `vault` CLI and must be run AFTER:
|
|
# 1. The vault-nodes are up and initialized (vault operator init on node-1)
|
|
# 2. VAULT_ADDR and VAULT_TOKEN are set in the environment
|
|
#
|
|
# Why no Vault Terraform provider here:
|
|
# - Adding the provider requires a working Vault cluster at `terraform init`
|
|
# - The cluster doesn't exist yet when this plan is first applied
|
|
# - The provider would encode the root token in TF state (undesirable)
|
|
# - A shell script run once post-bootstrap is simpler and more auditable
|
|
#
|
|
# If you want to add the Vault provider in a future iteration, the script
|
|
# below maps directly to `vault_auth_backend`, `vault_policy`, and
|
|
# `vault_gcp_auth_backend_role` resources.
|
|
|
|
# ── GCP Secret Manager secret for Vault auth init script ─────────────────────
|
|
# Store the post-init script here so it can be fetched from any node via
|
|
# gcloud secrets versions access — no file transfer needed.
|
|
|
|
resource "google_secret_manager_secret" "vault_auth_init_script" {
|
|
secret_id = "vault-auth-init-script"
|
|
project = var.project_id
|
|
|
|
replication {
|
|
auto {}
|
|
}
|
|
}
|
|
|
|
# ── Service account SA email data sources (for use in the configure script) ──
|
|
|
|
# The script uses these SA emails — surfaced here as outputs for convenience
|
|
|
|
output "vault_auth_sa_emails" {
|
|
description = "Service account emails for Vault GCP auth roles — used in configure-vault-auth.sh"
|
|
value = {
|
|
marketing = google_service_account.marketing.email
|
|
soma = google_service_account.soma.email
|
|
}
|
|
}
|