diff --git a/.secrets.baseline b/.secrets.baseline
index 0761e0a7b..3c7efd185 100644
--- a/.secrets.baseline
+++ b/.secrets.baseline
@@ -145,6 +145,15 @@
         "line_number": 46
       }
     ],
+    "docs/superpowers/plans/2026-08-24-gcp-openbao.md": [
+      {
+        "type": "Secret Keyword",
+        "filename": "docs/superpowers/plans/2026-08-24-gcp-openbao.md",
+        "hashed_secret": "13d26a89a916713f8f40cf05869c7b25c3e6ea54",
+        "is_verified": false,
+        "line_number": 857
+      }
+    ],
     "infrastructure/base/gapi/platform-private-gateway-certificate.yaml": [
       {
         "type": "Secret Keyword",
@@ -441,5 +450,5 @@
       }
     ]
   },
-  "generated_at": "2026-08-24T08:08:41Z"
+  "generated_at": "2026-08-24T17:05:57Z"
 }
diff --git a/docs/superpowers/plans/2026-08-24-gcp-openbao.md b/docs/superpowers/plans/2026-08-24-gcp-openbao.md
new file mode 100644
index 000000000..0d9b3445a
--- /dev/null
+++ b/docs/superpowers/plans/2026-08-24-gcp-openbao.md
@@ -0,0 +1,913 @@
+# OpenBao on GCP Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Give the GKE cluster a private certificate authority — OpenBao at `bao.priv.gcp.ogenki.io:8200`, issuing for `*.priv.gcp.ogenki.io` from an intermediate signed by an offline root.
+
+**Architecture:** Two OpenTofu stacks under `opentofu/gcp/openbao/`, mirroring the AWS split. `cluster/` builds a single-node zonal MIG behind an internal passthrough Network LB, auto-unsealed by Cloud KMS. `management/` runs the `vault` provider against the live endpoint and configures the PKI only. The root CA never touches a networked system; only the intermediate reaches GCP Secret Manager, imported directly as the issuer.
+
+**Tech Stack:** OpenTofu, Terramate, `google` provider, `vault` provider, GCP Secret Manager, Cloud KMS, Cloud DNS, External Secrets, cert-manager.
+
+**Spec:** [`docs/superpowers/specs/2026-08-24-gcp-openbao-design.md`](../specs/2026-08-24-gcp-openbao-design.md)
+
+## Global Constraints
+
+- **Domain:** `priv.gcp.ogenki.io`. Endpoint `bao.priv.gcp.ogenki.io:8200`.
+- **Region/zone:** `europe-west4` / `europe-west4-a` — zonal, matching the GKE cluster.
+- **CA key types:** root and intermediate `EC secp384r1`; OpenBao's server leaf `EC prime256v1` (P-256).
+- **Server leaf SAN:** DNS name only. **No IP SAN.**
+- **Key file permissions:** `chmod 600` — `openssl` writes world-readable by default.
+- **Secret Manager IDs** permit only letters, digits, `-`, `_`. No slashes, no dots.
+- **State backend:** S3 bucket `demo-smana-remote-backend`, region `eu-west-3` (the *bucket's* region, unrelated to the GCP region).
+- **Terramate gate:** every script guards on `TM_GCP_ENABLED=true` and no-ops with `[skip]` otherwise.
+- **No secret may be templated into instance metadata.** TLS material is fetched at boot from Secret Manager.
+- **Never commit CA private keys.** The root key never leaves offline storage; the intermediate key exists only in Secret Manager.
+
+### Verification model for this plan
+
+This is infrastructure, so "write a failing test first" means **run the verification command and watch it fail for the right reason**, then implement, then watch it pass. The gates are:
+
+| Layer | Command |
+|---|---|
+| OpenTofu | `tofu validate`, `trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .`, `tofu plan -var-file=variables.tfvars` |
+| Shell | `shellcheck <script>` |
+| Kubernetes manifests | `./scripts/validate-manifests.sh` → `Invalid: 0, Skipped: 0` |
+| Docs | `./scripts/validate-links.sh` |
+
+`tofu plan` against an undeployed stack is the closest analogue to a failing unit test: it proves the resource graph is right before anything is created.
+
+---
+
+### Task 1: IAM custom role for Secret Manager access
+
+External Secrets needs to read GCP Secret Manager, which needs a `GCPWorkloadIdentity` claim. The IAM condition in `gke/init` allowlists only `xplane_dns_editor`, so such a claim is refused at the provider. This adds the second grantable role. Independent of everything else in this plan and safe to merge alone.
+
+**Files:**
+- Modify: `opentofu/gcp/gke/init/iam.tf`
+
+**Interfaces:**
+- Consumes: nothing.
+- Produces: a custom role whose deterministic name is `projects/<project>/roles/xplane_secret_reader`, referenced by Task 8's claim.
+
+- [ ] **Step 1: Confirm the gap is real — the claim would currently be refused**
+
+Run:
+```bash
+cd opentofu/gcp/gke/init
+grep -A4 'crossplane_grantable_roles' iam.tf
+```
+Expected: the list contains only `google_project_iam_custom_role.crossplane_dns.name`. That is the failing state — a Secret Manager claim has no allowlisted role.
+
+- [ ] **Step 2: Add the custom role**
+
+In `opentofu/gcp/gke/init/iam.tf`, after the `crossplane_dns` resource:
+
+```hcl
+# The Secret Manager role External Secrets is permitted to receive.
+#
+# Pre-created for the same reason as crossplane_dns: `hasOnly` matches exact
+# role names, so a role the composition names at render time can never be
+# allowlisted. Deterministic name, therefore allowlistable.
+#
+# `versions.access` only. NOT secretmanager.secrets.create/delete — External
+# Secrets READS; anything that writes or destroys a secret is outside its job
+# and outside the platform constitution's "no deletion permissions for stateful
+# services" rule.
+resource "google_project_iam_custom_role" "crossplane_secret_reader" {
+  project     = var.project_id
+  role_id     = "xplane_secret_reader"
+  title       = "Crossplane Secret Manager reader"
+  description = "Read secret payloads for External Secrets. No create, no delete; see opentofu/gcp/gke/init/iam.tf."
+
+  permissions = [
+    "secretmanager.versions.access",
+    "secretmanager.versions.list",
+    "secretmanager.secrets.get",
+    "secretmanager.secrets.list",
+  ]
+}
+```
+
+- [ ] **Step 3: Add it to the allowlist**
+
+Change the `crossplane_grantable_roles` local to:
+
+```hcl
+  crossplane_grantable_roles = [
+    google_project_iam_custom_role.crossplane_dns.name,
+    google_project_iam_custom_role.crossplane_secret_reader.name,
+  ]
+```
+
+- [ ] **Step 4: Verify formatting, validity and the security gate**
+
+Run:
+```bash
+cd opentofu/gcp/gke/init
+tofu fmt -check iam.tf && tofu validate && trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+```
+Expected: all three exit 0.
+
+- [ ] **Step 5: Verify the condition now names two roles**
+
+Run:
+```bash
+cd opentofu/gcp/gke/init
+tofu console -var-file=variables.tfvars <<< 'local.crossplane_grant_condition'
+```
+Expected: output contains both `xplane_dns_editor` and `xplane_secret_reader`.
+If `tofu console` needs credentials and none are present, substitute:
+`grep -n 'google_project_iam_custom_role\.crossplane_secret_reader' iam.tf` → expect
+exactly one hit, inside the `crossplane_grantable_roles` local. Grep for the
+reference, not a count: `grep -c` counts matching LINES, and the trailing dot in
+that pattern matches only REFERENCES — `resource "google_project_iam_custom_role"`
+declarations use a quote and never match it.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add opentofu/gcp/gke/init/iam.tf
+git commit -m "feat(gcp): allowlist a Secret Manager reader role for External Secrets"
+```
+
+---
+
+### Task 2: `--cloud gcp` flag on `openbao-config.sh`
+
+The script is AWS-only. Its cloud coupling is three seams; this replaces them with dispatching helpers so both clouds share one entry point.
+
+**Files:**
+- Modify: `scripts/openbao-config.sh`
+
+**Interfaces:**
+- Consumes: nothing.
+- Produces: `openbao-config.sh --cloud gcp --project <id> init|ca`, used by Tasks 5 and 7.
+
+- [ ] **Step 1: Confirm the script rejects GCP today**
+
+Run:
+```bash
+./scripts/openbao-config.sh ca --cloud gcp --project ogenki-435905 \
+  --root-ca-secret-name openbao-priv-gcp-ca-chain --ca-output-file /tmp/ca.pem
+```
+Expected: FAIL — `--cloud` is an unknown option. That is the gap.
+
+- [ ] **Step 2: Add the flag and its validation to `parse_args`**
+
+Add near the other defaults (around line 26):
+```bash
+CLOUD="aws"
+PROJECT=""
+```
+
+Add to the `case` in `parse_args`:
+```bash
+            --cloud)                      CLOUD="$2"; shift 2 ;;
+            --project)                    PROJECT="$2"; shift 2 ;;
+```
+
+Add validation after parsing:
+```bash
+    case "$CLOUD" in
+        aws) ;;
+        gcp)
+            if [ -z "$PROJECT" ]; then
+                echo "Error: --project is required with --cloud gcp" >&2
+                exit 1
+            fi
+            # Fail here rather than at the API call: passing an AWS-only flag to
+            # GCP is a mistake about which cloud you are on, and the API error
+            # would not say so.
+            if [ -n "$PROFILE" ]; then
+                echo "Error: --profile is AWS-only and cannot be used with --cloud gcp" >&2
+                exit 1
+            fi
+            ;;
+        *)
+            echo "Error: --cloud must be 'aws' or 'gcp' (got '$CLOUD')" >&2
+            exit 1
+            ;;
+    esac
+```
+
+- [ ] **Step 3: Replace the two cloud seams with dispatching helpers**
+
+Add these functions, replacing the body of `create_or_update_secret` and the inline read in the `ca` path:
+
+```bash
+# Write a secret value, creating the secret if it does not exist.
+# Usage: secret_write <name> <value>
+secret_write() {
+    local name=$1 value=$2
+    if [ "$CLOUD" = "gcp" ]; then
+        if gcloud secrets describe "$name" --project "$PROJECT" >/dev/null 2>&1; then
+            printf '%s' "$value" | gcloud secrets versions add "$name" \
+                --project "$PROJECT" --data-file=- >/dev/null
+        else
+            printf '%s' "$value" | gcloud secrets create "$name" \
+                --project "$PROJECT" --replication-policy=automatic --data-file=- >/dev/null
+        fi
+    else
+        local aws_cmd; aws_cmd=$(get_aws_cmd)
+        if $aws_cmd secretsmanager describe-secret --secret-id "$name" >/dev/null 2>&1; then
+            $aws_cmd secretsmanager update-secret --secret-id "$name" --secret-string "$value" >/dev/null
+        else
+            $aws_cmd secretsmanager create-secret --name "$name" --secret-string "$value" >/dev/null
+        fi
+    fi
+}
+
+# Read the current value of a secret to stdout.
+# Usage: secret_read <name>
+secret_read() {
+    local name=$1
+    if [ "$CLOUD" = "gcp" ]; then
+        gcloud secrets versions access latest --secret "$name" --project "$PROJECT"
+    else
+        local aws_cmd; aws_cmd=$(get_aws_cmd)
+        $aws_cmd secretsmanager get-secret-value --secret-id "$name" \
+            --query SecretString --output text
+    fi
+}
+```
+
+Update the three call sites to use `secret_write "$NAME" "$VALUE"` and `secret_read "$NAME"`, dropping the `AWS_CMD` argument.
+
+- [ ] **Step 4: Update `usage()` and `check_prerequisites`**
+
+Add to `usage()`:
+```bash
+    echo "  --cloud <aws|gcp>                         Secret backend (default: aws)"
+    echo "  --project <Project ID>                    GCP project (required for --cloud gcp)"
+```
+
+In `check_prerequisites`, require `gcloud` when `CLOUD=gcp` and `aws` otherwise.
+
+- [ ] **Step 5: Verify with shellcheck**
+
+Run: `shellcheck scripts/openbao-config.sh`
+Expected: exit 0, no new warnings.
+
+- [ ] **Step 6: Verify the flag validation actually fires**
+
+Run:
+```bash
+./scripts/openbao-config.sh ca --cloud gcp --root-ca-secret-name x --ca-output-file /tmp/x
+```
+Expected: FAIL with `--project is required with --cloud gcp`.
+
+```bash
+./scripts/openbao-config.sh ca --cloud azure --project p --root-ca-secret-name x --ca-output-file /tmp/x
+```
+Expected: FAIL with `--cloud must be 'aws' or 'gcp'`.
+
+- [ ] **Step 7: Commit**
+
+```bash
+git add scripts/openbao-config.sh
+git commit -m "feat(openbao): add --cloud gcp to openbao-config.sh"
+```
+
+---
+
+### Task 3: Generate the PKI material and load Secret Manager
+
+The offline ceremony. This produces no code — it produces secrets and a written procedure. Do it before the cluster stack, because `cluster/` reads the server certificate at boot.
+
+**Files:**
+- Create: `docs/runbooks/gcp-openbao-pki-ceremony.md`
+
+**Interfaces:**
+- Consumes: nothing.
+- Produces: Secret Manager secrets `openbao-priv-gcp-intermediate-ca`, `openbao-priv-gcp-server-cert`, `openbao-priv-gcp-ca-chain` — consumed by Tasks 5, 7 and 8.
+
+- [ ] **Step 1: Confirm no PKI secrets exist yet**
+
+Run: `gcloud secrets list --project ogenki-435905 --format='value(name)' | grep openbao || echo NONE`
+Expected: `NONE`. That is the starting state.
+
+- [ ] **Step 2: Generate the offline root**
+
+On a machine you are willing to call offline for the duration, in a directory you will destroy afterwards:
+
+```bash
+umask 077
+openssl ecparam -genkey -name secp384r1 -out root-ca-key.pem
+openssl req -x509 -new -nodes -key root-ca-key.pem -sha384 -days 3653 \
+  -subj "/CN=Ogenki Root CA/O=Ogenki/C=FR" -out root-ca.pem
+chmod 600 root-ca-key.pem
+```
+
+- [ ] **Step 3: Generate and sign the GCP intermediate**
+
+```bash
+cat > intermediate-ca.cnf <<'EOF'
+[v3_req]
+basicConstraints = critical, CA:TRUE, pathlen:0
+keyUsage = critical, keyCertSign, cRLSign
+EOF
+
+openssl ecparam -genkey -name secp384r1 -out intermediate-ca-key.pem
+openssl req -new -key intermediate-ca-key.pem \
+  -subj "/CN=Ogenki GCP Intermediate CA/O=Ogenki/C=FR" -out intermediate-ca.csr
+openssl x509 -req -in intermediate-ca.csr -CA root-ca.pem -CAkey root-ca-key.pem \
+  -CAcreateserial -out intermediate-ca.pem -days 1827 -sha384 \
+  -extfile intermediate-ca.cnf -extensions v3_req
+chmod 600 intermediate-ca-key.pem
+```
+
+- [ ] **Step 4: Generate OpenBao's server leaf — P-256, DNS SAN only**
+
+```bash
+cat > server.cnf <<'EOF'
+[v3_req]
+basicConstraints = CA:FALSE
+keyUsage = critical, digitalSignature, keyEncipherment
+extendedKeyUsage = serverAuth
+subjectAltName = DNS:bao.priv.gcp.ogenki.io
+EOF
+
+openssl ecparam -genkey -name prime256v1 -out server-key.pem
+openssl req -new -key server-key.pem -subj "/CN=bao.priv.gcp.ogenki.io" -out server.csr
+openssl x509 -req -in server.csr -CA intermediate-ca.pem -CAkey intermediate-ca-key.pem \
+  -CAcreateserial -out server.pem -days 825 -sha256 \
+  -extfile server.cnf -extensions v3_req
+chmod 600 server-key.pem
+```
+
+- [ ] **Step 5: Verify the chain before uploading anything**
+
+```bash
+cat intermediate-ca.pem root-ca.pem > ca-chain.pem
+openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server.pem
+openssl x509 -in server.pem -noout -text | grep -A1 'Subject Alternative Name'
+```
+Expected: `server.pem: OK`, and the SAN line reads exactly `DNS:bao.priv.gcp.ogenki.io` with **no IP Address entry**. If an IP appears, regenerate — this is the constraint the spec calls out.
+
+- [ ] **Step 6: Upload to Secret Manager**
+
+```bash
+P=ogenki-435905
+
+jq -Rs '{bundle: .}' < <(cat intermediate-ca.pem intermediate-ca-key.pem) \
+  | gcloud secrets create openbao-priv-gcp-intermediate-ca \
+      --project "$P" --replication-policy=automatic --data-file=-
+
+jq -n --rawfile cert server.pem --rawfile key server-key.pem --rawfile ca ca-chain.pem \
+  '{cert: $cert, key: $key, ca: $ca}' \
+  | gcloud secrets create openbao-priv-gcp-server-cert \
+      --project "$P" --replication-policy=automatic --data-file=-
+
+gcloud secrets create openbao-priv-gcp-ca-chain \
+  --project "$P" --replication-policy=automatic --data-file=ca-chain.pem
+```
+
+The JSON shapes are deliberate: `{bundle}` matches what `vault_pki_secret_backend_config_ca` reads in Task 7, and `{cert,key,ca}` matches what the boot script's `jq -r '.cert'` reads in Task 5.
+
+- [ ] **Step 7: Move the root key offline and destroy the working directory**
+
+Copy `root-ca-key.pem` and `root-ca.pem` to whatever you have chosen as offline storage. Then:
+
+```bash
+shred -u root-ca-key.pem intermediate-ca-key.pem server-key.pem 2>/dev/null || rm -f root-ca-key.pem intermediate-ca-key.pem server-key.pem
+```
+
+**The root key must not exist on this machine or in any cloud afterwards.** Verify:
+```bash
+gcloud secrets list --project ogenki-435905 --format='value(name)' | grep -i root
+```
+Expected: only `openbao-priv-gcp-ca-chain` (certificates, no key). No secret holding the root private key.
+
+- [ ] **Step 8: Write the runbook**
+
+Write `docs/runbooks/gcp-openbao-pki-ceremony.md` containing Steps 2–7 verbatim, plus: where the root is stored, who can reach it, and the fact that re-running Step 4 alone is how the server certificate is re-issued if the hostname changes — which is the failure that stranded the AWS chain on 2026-08-23.
+
+- [ ] **Step 9: Commit**
+
+```bash
+git add docs/runbooks/gcp-openbao-pki-ceremony.md
+git commit -m "docs(gcp): OpenBao PKI ceremony runbook for the offline root"
+```
+
+---
+
+### Task 4: Cluster stack scaffolding — backend, KMS, service account, IAM
+
+**Files:**
+- Create: `opentofu/gcp/openbao/cluster/backend.tf`, `providers.tf`, `versions.tf`, `variables.tf`, `variables.tfvars`, `data.tf`, `kms.tf`, `iam.tf`, `locals.tf`, `stack.tm.hcl`, `workflows.tm.hcl`, `.trivyignore.yaml`, `trivy.yaml`
+
+**Interfaces:**
+- Consumes: Task 3's Secret Manager secrets.
+- Produces: `google_service_account.openbao.email`, `google_kms_crypto_key.openbao.id`, and `data.terraform_remote_state.network` outputs — all consumed by Tasks 5 and 6.
+
+- [ ] **Step 1: Confirm the stack does not exist**
+
+Run: `ls opentofu/gcp/openbao/cluster/ 2>&1`
+Expected: `No such file or directory`.
+
+- [ ] **Step 2: Create the backend, copying the S3 rationale**
+
+`opentofu/gcp/openbao/cluster/backend.tf`:
+```hcl
+# State lives in S3, not GCS, even though this stack manages GCP resources.
+# See opentofu/gcp/network/backend.tf for the full rationale.
+#
+# NOTE the hardcoded region. It is the S3 BUCKET's region and has nothing to do
+# with var.region, which in this stack is a GCP region (europe-west4).
+terraform {
+  backend "s3" {
+    bucket       = "demo-smana-remote-backend"
+    key          = "cloud-native-ref/gcp/openbao/cluster/opentofu.tfstate"
+    region       = "eu-west-3"
+    encrypt      = true
+    use_lockfile = true
+  }
+}
+```
+
+- [ ] **Step 3: Read the network stack's outputs**
+
+`opentofu/gcp/openbao/cluster/data.tf`:
+```hcl
+data "google_project" "this" {
+  project_id = var.project_id
+}
+
+data "terraform_remote_state" "network" {
+  backend = "s3"
+
+  config = {
+    bucket = "demo-smana-remote-backend"
+    key    = "cloud-native-ref/gcp/network/opentofu.tfstate"
+    # Literal, NOT var.region: this is the S3 bucket's region, while var.region
+    # in this stack is a GCP region (europe-west4).
+    region = "eu-west-3"
+  }
+}
+```
+
+`locals.tf`:
+```hcl
+locals {
+  network             = data.terraform_remote_state.network.outputs
+  subnetwork_self_link = local.network.nodes_subnetwork_self_link
+  private_dns_zone    = local.network.private_dns_zone_name
+  private_domain_name = local.network.private_domain_name
+  fqdn                = "bao.${local.network.private_domain_name}"
+}
+```
+
+- [ ] **Step 4: Create the Cloud KMS key for auto-unseal**
+
+`kms.tf`:
+```hcl
+# Auto-unseal. The instance service account gets encrypter/decrypter on this key
+# and nothing else — it never needs to manage the key, only use it.
+#
+# prevent_destroy is deliberate: destroying the key makes every sealed OpenBao
+# permanently unrecoverable. Cloud KMS keys cannot truly be deleted anyway
+# (versions are scheduled for destruction), so a teardown leaves the key ring
+# behind by design. It costs nothing when idle.
+resource "google_kms_key_ring" "openbao" {
+  name     = "openbao-${var.env}"
+  project  = var.project_id
+  location = var.region
+}
+
+resource "google_kms_crypto_key" "openbao" {
+  name     = "openbao-unseal"
+  key_ring = google_kms_key_ring.openbao.id
+  purpose  = "ENCRYPT_DECRYPT"
+
+  lifecycle {
+    prevent_destroy = true
+  }
+}
+```
+
+- [ ] **Step 5: Create the service account and its scoped bindings**
+
+`iam.tf`:
+```hcl
+resource "google_service_account" "openbao" {
+  account_id   = "openbao-${var.env}"
+  display_name = "OpenBao node"
+  project      = var.project_id
+}
+
+# Unseal only. Not admin on the key.
+resource "google_kms_crypto_key_iam_member" "openbao_unseal" {
+  crypto_key_id = google_kms_crypto_key.openbao.id
+  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
+  member        = "serviceAccount:${google_service_account.openbao.email}"
+}
+
+# Read the server certificate at boot. Scoped to that ONE secret — not
+# project-wide secretAccessor, which would let the node read Flux's GitHub App
+# credentials and every other secret in the project.
+resource "google_secret_manager_secret_iam_member" "openbao_server_cert" {
+  project   = var.project_id
+  secret_id = var.server_cert_secret_name
+  role      = "roles/secretmanager.secretAccessor"
+  member    = "serviceAccount:${google_service_account.openbao.email}"
+}
+```
+
+- [ ] **Step 6: Create variables with the spec's values as defaults**
+
+`variables.tf` — `project_id`, `region` (default `europe-west4`), `zone` (default `europe-west4-a`), `env` (default `dev`), `machine_type` (default `e2-small`), `openbao_version`, `data_disk_size_gb` (default 10), `server_cert_secret_name` (default `openbao-priv-gcp-server-cert`), `openbao_data_path` (default `/opt/openbao/data`).
+
+`variables.tfvars` sets `project_id = "ogenki-435905"` and leaves the rest on defaults, with a comment saying why each non-default exists.
+
+- [ ] **Step 7: Create the Terramate wiring**
+
+`stack.tm.hcl` mirroring `opentofu/gcp/network/stack.tm.hcl`, with `after` pointing at the network stack. `workflows.tm.hcl` with `deploy`, `preview`, `destroy`, `init`, `drift detect|reconcile` and `opentofu render` scripts, each guarded by `TM_GCP_ENABLED`.
+
+**The `destroy` script must use the tolerant pattern**, not a bare `tofu destroy` — see `opentofu/gcp/gke/configure/workflows.tm.hcl` for why a strict destroy in a `--reverse` run strands billable resources.
+
+Create `.trivyignore.yaml` with `misconfigurations: []` and `trivy.yaml` with `scan.skip-dirs: [.terraform]`, copying the comments from `opentofu/gcp/gke/init/`.
+
+- [ ] **Step 8: Verify the stack initialises and plans**
+
+Run:
+```bash
+cd opentofu/gcp/openbao/cluster
+tofu init -backend=false && tofu validate && tofu fmt -check
+trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+```
+Expected: all exit 0.
+
+- [ ] **Step 9: Commit**
+
+```bash
+git add opentofu/gcp/openbao/cluster/
+git commit -m "feat(gcp): OpenBao cluster stack scaffolding, KMS and IAM"
+```
+
+---
+
+### Task 5: Cluster compute — instance template, MIG, boot script
+
+**Files:**
+- Create: `opentofu/gcp/openbao/cluster/compute.tf`, `scripts/startup-script.sh`, `scripts/setup-local-disks.sh`
+
+**Interfaces:**
+- Consumes: Task 4's `google_service_account.openbao.email`, `google_kms_crypto_key.openbao.id`, `local.subnetwork_self_link`, `local.fqdn`.
+- Produces: `google_compute_instance_group_manager.openbao.instance_group` — consumed by Task 6's backend service.
+
+- [ ] **Step 1: Port the disk setup script**
+
+Copy `opentofu/aws/openbao/cluster/scripts/setup-local-disks.sh` to the new stack, replacing NVMe device discovery with GCP's stable symlink `/dev/disk/by-id/google-openbao-data`. Keep the idempotency check — the script runs on every boot, not only the first.
+
+- [ ] **Step 2: Port the startup script**
+
+`scripts/startup-script.sh`, templated with exactly these variables — the list
+must match what the config block below references, or `templatefile` fails at
+plan time:
+
+`openbao_version`, `openbao_data_path`, `project_id`, `region`,
+`kms_key_ring`, `kms_crypto_key`, `server_cert_secret_name`, `fqdn`.
+
+Pass the key ring and key by NAME (`google_kms_key_ring.openbao.name`,
+`google_kms_crypto_key.openbao.name`), not by id.
+
+Carry over verbatim from the AWS script:
+- The pinned GPG fingerprint check `66D15FDD87287219C8E15478D200CD702853E6D0` and the reasoning comment — without it the key is fetched and trusted on sight.
+- The header warning that **nothing secret may be templated into this file**; GCP instance metadata is readable from the metadata server by anything on the box.
+
+Replace the AWS-specific parts:
+```bash
+# Instance identity from the GCP metadata server (IMDS equivalent).
+PRIVATE_IP=$(curl -fsS -H "Metadata-Flavor: Google" \
+  http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip)
+
+install -d -m 0750 -o root -g openbao /opt/openbao/tls
+
+TLS_SECRET=$(gcloud secrets versions access latest \
+  --secret "${server_cert_secret_name}" --project "${project_id}")
+
+umask 077
+printf '%s' "$TLS_SECRET" | jq -r '.cert' > /opt/openbao/tls/tls.crt
+printf '%s' "$TLS_SECRET" | jq -r '.key'  > /opt/openbao/tls/tls.key
+printf '%s' "$TLS_SECRET" | jq -r '.ca'   > /opt/openbao/tls/ca.pem
+unset TLS_SECRET
+
+chown root:openbao /opt/openbao/tls/tls.key
+chmod 0640 /opt/openbao/tls/tls.key
+chmod 0644 /opt/openbao/tls/tls.crt /opt/openbao/tls/ca.pem
+```
+
+And the config, with `gcpckms` replacing `awskms`:
+```bash
+cat << EOF > /etc/openbao/openbao.hcl
+cluster_addr = "https://$PRIVATE_IP:8201"
+api_addr     = "https://${fqdn}:8200"
+ui           = true
+
+listener "tcp" {
+  address         = "[::]:8200"
+  cluster_address = "[::]:8201"
+  tls_cert_file   = "/opt/openbao/tls/tls.crt"
+  tls_key_file    = "/opt/openbao/tls/tls.key"
+}
+
+storage "file" {
+  path = "${openbao_data_path}"
+}
+
+seal "gcpckms" {
+  project    = "${project_id}"
+  region     = "${region}"
+  key_ring   = "${kms_key_ring}"
+  crypto_key = "${kms_crypto_key}"
+}
+EOF
+```
+
+Note `gcpckms` takes key ring and key **names**, not the fully-qualified id — passing the id is a common error that fails at unseal, not at boot.
+
+- [ ] **Step 3: Create the instance template and MIG**
+
+`compute.tf`, with `metadata_startup_script = templatefile(...)`, the service account attached with scope `cloud-platform`, a 10 GB `pd-balanced` data disk named `openbao-data`, `shielded_instance_config` enabled, and a MIG with `target_size = 1`.
+
+- [ ] **Step 4: Verify shell and OpenTofu**
+
+Run:
+```bash
+shellcheck -e SC2154 opentofu/gcp/openbao/cluster/scripts/*.sh
+cd opentofu/gcp/openbao/cluster && tofu validate && tofu fmt -check
+trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+```
+Expected: all exit 0. `SC2154` is excluded because the scripts reference variables that `templatefile` substitutes.
+
+- [ ] **Step 5: Commit**
+
+```bash
+git add opentofu/gcp/openbao/cluster/
+git commit -m "feat(gcp): OpenBao instance template, MIG and boot script"
+```
+
+---
+
+### Task 6: Internal load balancer, firewall and DNS
+
+**Files:**
+- Create: `opentofu/gcp/openbao/cluster/load_balancer.tf`, `firewall.tf`, `dns.tf`, `outputs.tf`
+
+**Interfaces:**
+- Consumes: Task 5's `instance_group`, Task 4's `local.private_dns_zone`.
+- Produces: outputs `endpoint` (`https://bao.priv.gcp.ogenki.io:8200`) and `service_account_email`, consumed by Task 7.
+
+- [ ] **Step 1: Create the internal passthrough Network LB**
+
+`load_balancer.tf` — a regional `google_compute_health_check` (TCP 8200; **not** HTTPS, because the health check would need to trust the private CA), a `google_compute_region_backend_service` with `load_balancing_scheme = "INTERNAL"` and protocol TCP, and a `google_compute_forwarding_rule` on port 8200 whose `ip_address` is a
+reserved `google_compute_address.openbao` — declare it here with
+`address_type = "INTERNAL"` and the node subnetwork, because Task 6 Step 3's DNS
+record refers to `google_compute_address.openbao.address` by that exact name.
+
+- [ ] **Step 2: Create firewall rules**
+
+`firewall.tf` — allow TCP 8200 from the node subnet and the tailnet advertised routes (`local.network.advertised_routes`), and allow the Google health-check ranges `130.211.0.0/22` and `35.191.0.0/16` on 8200. Add the IAP range `35.235.240.0/20` on TCP 22 behind a `var.enable_iap_ssh` flag defaulting to `false`, with a comment that the tailnet already reaches the subnet and an always-on admin path is a standing exposure.
+
+- [ ] **Step 3: Create the DNS record**
+
+`dns.tf`:
+```hcl
+resource "google_dns_record_set" "openbao" {
+  project      = var.project_id
+  managed_zone = local.private_dns_zone
+  name         = "${local.fqdn}."
+  type         = "A"
+  ttl          = 60
+  rrdatas      = [google_compute_address.openbao.address]
+}
+```
+
+- [ ] **Step 4: Verify, then deploy for real**
+
+Run:
+```bash
+cd opentofu/gcp/openbao/cluster
+tofu validate && tofu fmt -check && trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+TM_GCP_ENABLED=true terramate script run --disable-check-git-remote deploy
+```
+Expected: apply completes. **Read the output, not the exit code** — Terramate has reported exit 0 over a failed run repeatedly in this repository.
+
+- [ ] **Step 5: Verify the node came up and can be initialised**
+
+```bash
+export VAULT_ADDR=https://bao.priv.gcp.ogenki.io:8200
+gcloud secrets versions access latest --secret openbao-priv-gcp-ca-chain \
+  --project ogenki-435905 > /tmp/gcp-ca.pem
+export VAULT_CACERT=/tmp/gcp-ca.pem
+bao status
+```
+Expected: `Initialized false`, `Sealed true`. If TLS fails to verify, the server leaf or chain is wrong — go back to Task 3 Step 5.
+
+```bash
+./scripts/openbao-config.sh init --cloud gcp --project ogenki-435905 \
+  --url https://bao.priv.gcp.ogenki.io:8200 \
+  --root-token-secret-name openbao-priv-gcp-root-token \
+  --recovery-keys-secret-name openbao-priv-gcp-recovery-keys
+bao status
+```
+Expected: `Initialized true`, `Sealed false` — sealed false **without** an unseal command proves `gcpckms`.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add opentofu/gcp/openbao/cluster/
+git commit -m "feat(gcp): OpenBao internal load balancer, firewall and DNS"
+```
+
+---
+
+### Task 7: Management stack — PKI
+
+**Files:**
+- Create: `opentofu/gcp/openbao/management/{backend,providers,versions,variables,data,pki,roles,auth,policies,outputs}.tf`, `variables.tfvars`, `stack.tm.hcl`, `workflows.tm.hcl`
+
+**Interfaces:**
+- Consumes: Task 6's endpoint, Task 3's `openbao-priv-gcp-intermediate-ca`.
+- Produces: Secret Manager secret `openbao-priv-gcp-approle-cert-manager` holding `{role_id, secret_id}` — consumed by Task 8.
+
+- [ ] **Step 1: Verify the untested assumption FIRST**
+
+The spec flags one assumption the whole chain rests on: that `config_ca` alone leaves the mount able to issue, without the CSR/sign/set-signed sequence. Test it by hand before writing any HCL:
+
+```bash
+export VAULT_ADDR=https://bao.priv.gcp.ogenki.io:8200 VAULT_CACERT=/tmp/gcp-ca.pem
+export VAULT_TOKEN=$(gcloud secrets versions access latest \
+  --secret openbao-priv-gcp-root-token --project ogenki-435905 | jq -r '.root_token')
+
+bao secrets enable -path=pki_test pki
+gcloud secrets versions access latest --secret openbao-priv-gcp-intermediate-ca \
+  --project ogenki-435905 | jq -r '.bundle' | bao write pki_test/config/ca pem_bundle=-
+bao write pki_test/roles/test allowed_domains=priv.gcp.ogenki.io allow_subdomains=true max_ttl=72h
+bao write pki_test/issue/test common_name=probe.priv.gcp.ogenki.io ttl=1h
+```
+Expected: the last command returns a certificate. **If it fails, stop and revisit the design** — the four removed resources may be required after all. Clean up: `bao secrets disable pki_test`.
+
+- [ ] **Step 2: Create the vault provider wiring**
+
+`providers.tf` reading the root token from GCP Secret Manager via `data.google_secret_manager_secret_version`, mirroring how the AWS management stack reads it from Secrets Manager.
+
+- [ ] **Step 3: Create the PKI mount and import the intermediate**
+
+`pki.tf`:
+```hcl
+resource "vault_mount" "pki" {
+  path                      = var.pki_mount_path
+  type                      = "pki"
+  description               = var.pki_common_name
+  default_lease_ttl_seconds = var.pki_max_lease_ttl
+  max_lease_ttl_seconds     = var.pki_max_lease_ttl
+}
+
+# The openssl-made intermediate IS the issuer. Unlike the AWS stack there is no
+# vault_pki_secret_backend_key / intermediate_cert_request / root_sign_intermediate
+# / intermediate_set_signed sequence: that exists only to generate an
+# OpenBao-internal intermediate under an imported ROOT, and this design never
+# imports the root. Verified by hand before this was written — see the plan.
+resource "vault_pki_secret_backend_config_ca" "pki" {
+  backend    = vault_mount.pki.path
+  pem_bundle = jsondecode(data.google_secret_manager_secret_version.intermediate_ca.secret_data).bundle
+}
+```
+
+- [ ] **Step 4: Create the cert-manager role, policy and AppRole**
+
+Port `roles.tf`, `policies.tf` and the `cert_manager` AppRole from `opentofu/aws/openbao/management/`, changing `allowed_domains` to `priv.gcp.ogenki.io`. Do **not** port the snapshot AppRole, the `app` namespace, the kv-v2 mount or the userpass backend.
+
+Write the AppRole credentials to Secret Manager:
+```hcl
+resource "google_secret_manager_secret" "approle_cert_manager" {
+  project   = var.project_id
+  secret_id = "openbao-priv-gcp-approle-cert-manager"
+  replication { auto {} }
+}
+
+resource "google_secret_manager_secret_version" "approle_cert_manager" {
+  secret = google_secret_manager_secret.approle_cert_manager.id
+  secret_data = jsonencode({
+    role_id   = vault_approle_auth_backend_role.cert_manager.role_id
+    secret_id = vault_approle_auth_backend_role_secret_id.cert_manager.secret_id
+  })
+}
+```
+
+- [ ] **Step 5: Deploy and verify issuance through the real mount**
+
+```bash
+cd opentofu/gcp/openbao/management
+TM_GCP_ENABLED=true terramate script run --disable-check-git-remote deploy
+bao write pki_private_issuer/issue/ogenki common_name=probe.priv.gcp.ogenki.io ttl=1h
+```
+Expected: a certificate is returned. Verify it chains to the offline root:
+```bash
+bao write -field=certificate pki_private_issuer/issue/ogenki \
+  common_name=probe.priv.gcp.ogenki.io ttl=1h > /tmp/probe.pem
+openssl verify -CAfile /tmp/gcp-ca.pem /tmp/probe.pem
+```
+Expected: `/tmp/probe.pem: OK`.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add opentofu/gcp/openbao/management/
+git commit -m "feat(gcp): OpenBao management stack — PKI from an offline root"
+```
+
+---
+
+### Task 8: GKE wiring — External Secrets and cert-manager
+
+**Files:**
+- Create: `security/gcp-mycluster-0/openbao/{gcpworkloadidentity,secretstore,externalsecrets,clusterissuer}.yaml`, `kustomization.yaml`
+- Create: `clusters/gcp-mycluster-0/security/security.yaml`
+
+**Interfaces:**
+- Consumes: Task 1's `xplane_secret_reader`, Task 7's AppRole secret, Task 3's CA chain.
+- Produces: a working `ClusterIssuer` named `openbao`.
+
+- [ ] **Step 1: Confirm the cluster has no issuer yet**
+
+Run: `kubectl get clusterissuer 2>&1`
+Expected: `No resources found` or the CRD is absent. That is the failing state.
+
+- [ ] **Step 2: Create the GCPWorkloadIdentity claim for External Secrets**
+
+```yaml
+apiVersion: cloud.ogenki.io/v1alpha1
+kind: GCPWorkloadIdentity
+metadata:
+  name: xplane-external-secrets
+  namespace: security
+spec:
+  serviceAccount:
+    name: external-secrets
+  roles:
+    - "projects/ogenki-435905/roles/xplane_secret_reader"
+```
+
+Note there is no `namespace` under `serviceAccount` — the composition derives it from the claim, which is why the claim must live in the same namespace as the ServiceAccount.
+
+- [ ] **Step 3: Create the ClusterSecretStore, ExternalSecrets and ClusterIssuer**
+
+A `ClusterSecretStore` with `provider.gcpsm` pointing at project `ogenki-435905`; two `ExternalSecret`s pulling `openbao-priv-gcp-approle-cert-manager` and `openbao-priv-gcp-ca-chain`; and a `ClusterIssuer` with `spec.vault.server: https://bao.priv.gcp.ogenki.io:8200`, `path: pki_private_issuer/sign/ogenki`, `caBundleSecretRef` and AppRole auth — modelled on `security/base/cert-manager/openbao-clusterissuer.yaml`.
+
+**Prefer per-secret bindings over the project-wide `xplane_secret_reader` role
+for these two secrets.** `xplane_secret_reader` (Task 1) grants
+`secretmanager.versions.access` project-wide via `ProjectIAMMember` — anyone
+holding it can read any secret in the project by name, including
+`openbao-priv-gcp-root-token`, `openbao-priv-gcp-recovery-keys` and the
+intermediate CA's private key, not just the two this claim needs. The
+preferred shape is `google_secret_manager_secret_iam_member` bound to exactly
+`openbao-priv-gcp-approle-cert-manager` and `openbao-priv-gcp-ca-chain`,
+mirroring what `opentofu/gcp/openbao/cluster/iam.tf` already does for the
+server certificate — which would make granting `xplane_secret_reader` to
+External Secrets unnecessary. Decide this when writing Task 8's OpenTofu, not
+by defaulting to the allowlisted role because it is already there.
+
+- [ ] **Step 4: Validate the manifests before applying**
+
+Run: `./scripts/validate-manifests.sh`
+Expected: exit 0 and `Invalid: 0, Skipped: 0`.
+
+- [ ] **Step 5: Verify end to end with a real certificate**
+
+```bash
+kubectl apply -f - <<'EOF'
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata: {name: probe, namespace: security}
+spec:
+  secretName: probe-tls
+  commonName: probe.priv.gcp.ogenki.io
+  dnsNames: [probe.priv.gcp.ogenki.io]
+  issuerRef: {name: openbao, kind: ClusterIssuer}
+EOF
+kubectl wait --for=condition=Ready certificate/probe -n security --timeout=120s
+kubectl get secret probe-tls -n security -o jsonpath='{.data.tls\.crt}' \
+  | base64 -d | openssl verify -CAfile /tmp/gcp-ca.pem /dev/stdin
+```
+Expected: `Ready=True`, and the chain verifies to the offline root. Then `kubectl delete certificate probe -n security`.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add security/gcp-mycluster-0/ clusters/gcp-mycluster-0/security/
+git commit -m "feat(gcp): wire cert-manager to OpenBao via External Secrets"
+```
+
+---
+
+## Final verification
+
+Run against the live cluster, then tear everything down.
+
+- [ ] Success criteria 1–8 from the [spec](../specs/2026-08-24-gcp-openbao-design.md#success-criteria), each with its command output cited.
+- [ ] `TM_GCP_ENABLED=true terramate script run deploy` a second time → 0-change plan on both stacks.
+- [ ] Teardown, then `gcloud compute instances list`, `gcloud container clusters list` and `gcloud secrets list | grep -i root` all empty of this workstream's resources.
+
+**The KMS key ring survives teardown by design** (`prevent_destroy`), because destroying it would make any sealed OpenBao unrecoverable. It costs nothing idle. Do not treat it as a teardown leak.
diff --git a/docs/superpowers/specs/2026-08-18-gcp-support-design.md b/docs/superpowers/specs/2026-08-18-gcp-support-design.md
index f8bd66e3e..93d035502 100644
--- a/docs/superpowers/specs/2026-08-18-gcp-support-design.md
+++ b/docs/superpowers/specs/2026-08-18-gcp-support-design.md
@@ -402,10 +402,11 @@ GCP certificate issuance hard-depend on AWS *and* on the tailnet, in a platform
 whose stated point is that each cloud stands alone. It is the same coupling this
 design already flags as undesirable for the Flux GitHub App secret.
 
-**B — Two OpenBaos, two roots. CHOSEN.** Each cloud runs its own OpenBao with its
-own root CA. Fully independent; matches [ADR-0007](../../../website/content/docs/decisions/0007-cloud-abstraction-boundaries.md)'s
+**B — Two OpenBaos, two roots. ~~CHOSEN~~ SUPERSEDED 2026-08-24.** Each cloud runs
+its own OpenBao with its own root CA. Fully independent; matches [ADR-0007](../../../website/content/docs/decisions/0007-cloud-abstraction-boundaries.md)'s
 rule that platform-facing infrastructure stays cloud-shaped. Costs one extra
-trust anchor for tailnet clients.
+trust anchor for tailnet clients — and, as written here, leaves a live root key
+in each cloud.
 
 **C — Two OpenBaos, one shared root.** Each cloud holds its own intermediate,
 both signed by a common root: one trust anchor, independent operation. Rejected
@@ -415,7 +416,23 @@ holds, or cross-signing GCP's intermediate at bootstrap, which is a manual
 ceremony **on every rebuild** of a platform whose lifecycle is
 build-validate-destroy.
 
-#### Why B, concretely
+> **That rejection was wrong, and C is now the chosen shape.** The "ceremony on
+> every rebuild" premise is false: the intermediate lives in Secret Manager
+> independently of OpenBao's lifecycle, which is exactly why AWS's survives
+> rebuilds today. Signing happens once per cloud, ever. Nor does a shared root
+> require copying the root key anywhere — with a genuinely OFFLINE root it is
+> never in any cloud's secret store. See
+> [the OpenBao-on-GCP design](./2026-08-24-gcp-openbao-design.md).
+
+#### Why B was chosen, and why it no longer is
+
+> **Superseded 2026-08-24.** The reasoning below is preserved because the failure
+> it describes is real and worth keeping; the conclusion drawn from it was too
+> narrow. The lesson is that a signing key must be held outside OpenBao — not
+> that each cloud needs its own root. An offline root shared across clouds
+> satisfies the same lesson and additionally keeps the root key off every
+> networked system. The current decision is in
+> [the OpenBao-on-GCP design](./2026-08-24-gcp-openbao-design.md).
 
 The 2026-08-24 rebuild made the argument better than theory could. The private
 domain rename forced a new server certificate, and re-issuing it under the
@@ -430,8 +447,9 @@ extra trust anchor and remove the entire class.
 
 #### Consequences to carry into workstream 11
 
-- Tailnet clients must trust **both** roots. That is the accepted cost; it is a
-  one-line addition wherever the AWS root is already distributed.
+- Tailnet clients trust **two anchors only until AWS migrates** — its existing
+  live-key root, and the new offline root. Under the superseded two-root decision
+  this was permanent; it is now an interim state with a defined end.
 - GCP needs its own secret store for the root token and the cert-manager AppRole
   — **GCP Secret Manager**, mirroring what AWS Secrets Manager does today. The
   `flux-github-app` secret already establishes that pattern on GCP.
diff --git a/docs/superpowers/specs/2026-08-24-gcp-openbao-design.md b/docs/superpowers/specs/2026-08-24-gcp-openbao-design.md
new file mode 100644
index 000000000..5887a8925
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-24-gcp-openbao-design.md
@@ -0,0 +1,290 @@
+# OpenBao on GCP — private PKI for the GKE cluster
+
+**Status:** design approved 2026-08-24, not yet implemented
+**Workstream:** 11 of the [GCP support design](./2026-08-18-gcp-support-design.md)
+**Depends on:** workstream 1 (GCP network) — deployed. Also needs one addition to
+workstream 5's IAM allowlist; see *A dependency on slice 5* below.
+
+## Why
+
+GCP has no private certificate authority. The GKE cluster can issue nothing for
+`*.priv.gcp.ogenki.io`, which blocks every private-TLS consumer the AWS platform
+takes for granted. AWS solves this with OpenBao at `bao.priv.aws.ogenki.io`; GCP
+needs its own, because [`opentofu/aws/openbao/`](../../../opentofu/aws/openbao/)
+is AWS-shaped throughout — ASG, ELB, KMS, Route53, and Secrets Manager for every
+credential.
+
+## Scope
+
+**PKI only.** A root of trust, an issuing CA, a cert-manager role and one
+AppRole. Deliberately NOT ported: the `app` tenant namespace, its kv-v2 mount,
+the snapshot AppRole, and operator userpass login. None has a consumer on GCP,
+and the GCP tree has been built minimal-until-needed throughout.
+
+## Decisions
+
+| Decision | Choice | Why |
+|---|---|---|
+| Scope | PKI only | No GCP consumer for the rest yet |
+| Topology | Single node, `file` backend | Mirrors what AWS actually runs (`mode = "dev"` is committed); cheapest for a build-validate-destroy platform |
+| Root CA custody | **Offline**. Signs GCP's intermediate now; becomes the shared anchor when AWS migrates | See *The PKI reconsideration* |
+| cert-manager auth | AppRole via GCP Secret Manager + External Secrets | Parity with AWS; the existing `security/base/cert-manager` manifests work with only the SecretStore backend changed |
+| Stack split | Two stacks, `cluster/` + `management/` | The `vault` provider needs a reachable, initialised server at plan time — the same constraint that splits `gke/init` from `gke/configure` |
+
+## The PKI reconsideration
+
+**This supersedes the two-root decision recorded in the GCP support design's
+*Private certificates on GCP* section.** That section is amended to point here.
+
+### What was wrong
+
+The AWS design imports a pem_bundle containing the **root key** into the live
+`pki_private_issuer` mount, then has OpenBao generate its own intermediate and
+sign it internally. [`pki-and-secrets.md`](../../../website/content/docs/platform/security/pki-and-secrets.md)
+documents this and warns against it verbatim: *"do not carry it into a deployment
+where the root CA matters."* The first draft of this design carried it into GCP
+anyway.
+
+It inverts the property an offline root exists to provide. A root signs
+intermediates a handful of times in its life; keeping it off any
+network-reachable system means compromising the issuing CA does not compromise
+the trust anchor. As written, compromising OpenBao yields the root.
+
+The earlier two-root decision was also rejected-for-the-wrong-reason. It ruled
+out a shared root because cross-signing would be *"a manual ceremony on every
+rebuild"*. That premise is false: the intermediate lives in Secret Manager
+independently of OpenBao's lifecycle, which is precisely why AWS's survives
+rebuilds today. Signing happens **once per cloud, ever**. The better option was
+rejected over a cost it does not have.
+
+### The chain
+
+```
+Offline Root CA (EC secp384r1) — never on a networked system
+  ├── GCP intermediate (EC secp384r1) → imported as pki_private_issuer → leaves
+  └── AWS intermediate                → later; see Migration below
+```
+
+The root signs the GCP intermediate's CSR **once, offline**, then returns to
+offline storage. Only the intermediate's certificate and key reach GCP Secret
+Manager. `vault_pki_secret_backend_config_ca` imports that bundle and it *is*
+the issuer.
+
+This also removes work. The AWS sequence —
+`vault_pki_secret_backend_key` → `intermediate_cert_request` →
+`root_sign_intermediate` → `intermediate_set_signed` — exists only to generate
+an OpenBao-internal intermediate under an imported root. Importing the
+openssl-made intermediate directly deletes all four resources.
+
+**The root key is never in Secret Manager, never in the mount, never in
+OpenTofu state.**
+
+### Migration, and the interim cost
+
+GCP adopts this first; AWS follows later. Until it does, tailnet clients trust
+**two** anchors — AWS's existing live-key root and the new offline root. That is
+the same cost as the two-root design being abandoned, but temporary with a
+defined end rather than permanent by construction.
+
+Migrating AWS means a new intermediate signed by the offline root and a
+coordinated re-trust. Out of scope here.
+
+## Architecture
+
+Two stacks under `opentofu/gcp/openbao/`.
+
+| AWS | GCP |
+|---|---|
+| Auto Scaling Group + launch template | Zonal MIG + instance template (`europe-west4-a`) |
+| Internal NLB, TCP 8200 | Internal passthrough Network LB — forwarding rule, backend service, health check |
+| `aws_kms_key` | `google_kms_key_ring` + `google_kms_crypto_key` |
+| Route53 private A record | `google_dns_record_set` in the existing `priv-gcp-ogenki-io` zone |
+| Security group | `google_compute_firewall` |
+| Instance profile + role policies | `google_service_account` + scoped Secret Manager / KMS bindings |
+| Secrets Manager | GCP Secret Manager |
+| cloud-init `user_data` | metadata `startup-script` |
+
+**Zonal is a real availability property, not an oversight.** The node dies with
+the zone. That is consistent with the GKE cluster, which is also zonal, and with
+a platform that is rebuilt rather than repaired.
+
+### Deliberately not ported
+
+- **Hardened-image plumbing.** AWS carries `ami_owner` / `ami_filter` variables
+  that are commented out and unused. Copying them would be copying scaffolding.
+- **The `mode` variable.** AWS defines `dev`/`ha` and commits `dev`. A variable
+  with one reachable value is worse than a constant, and the HA path would ship
+  untested. Single node, stated plainly.
+- **An always-on admin path.** AWS keeps SSM enabled because it is how you reach
+  a node whose boot script failed. GCP's counterpart is IAP TCP forwarding. The
+  firewall rule is written but disabled by default: the tailnet already reaches
+  the subnet, and an always-on admin path is a standing exposure.
+
+## Boot sequence
+
+Per instance, via metadata `startup-script`:
+
+1. Format and mount the data disk.
+2. Install a pinned OpenBao version.
+3. Fetch the server leaf certificate and key from Secret Manager using the
+   instance service account.
+4. Write config: TLS listener on 8200, `file` storage, and a `gcpckms` seal
+   stanza. The instance service account needs
+   `cloudkms.cryptoKeyEncrypterDecrypter` on that key and nothing else.
+5. Start the service.
+
+Initialisation stays a separate, deliberate step —
+`scripts/openbao-config.sh init` — as on AWS. An auto-init path was considered
+and rejected: a documented procedure already exists, and a second one is how the
+two clouds drift.
+
+### Certificate details to carry forward
+
+From `pki-and-secrets.md`, all three still apply:
+
+- OpenBao's own leaf is **EC P-256** against the P-384 CAs.
+- `openssl` writes key files world-readable — `chmod 600`. This key terminates
+  TLS for every client.
+- The SAN list carries the **DNS name only, no IP**. On AWS that is why a client
+  reaching a Raft peer by private IP cannot verify TLS. Single-node here makes it
+  moot today; the constraint stays so it does not surprise a future HA change.
+
+## Management stack
+
+Mirrors AWS's `pki.tf` with the data source swapped and the internal-intermediate
+sequence removed:
+
+- `vault_mount` — the `pki_private_issuer` mount
+- `vault_pki_secret_backend_config_ca` — imports the intermediate bundle from
+  GCP Secret Manager
+- `vault_pki_secret_backend_issuer` — to name the issuer `config_ca` creates and
+  set its usage. Whether this resource is needed at all depends on the same
+  assumption flagged in *Risks*: confirm what `config_ca` leaves behind before
+  writing it, rather than porting it from AWS on faith
+- a cert-manager role scoped to `priv.gcp.ogenki.io`
+- one AppRole, whose `role-id` / `secret-id` are written to Secret Manager
+
+## `openbao-config.sh` gains `--cloud gcp`
+
+The script is AWS-only today. Its coupling is contained to three seams, which is
+what makes a flag the right shape rather than a sibling script:
+
+| Seam | AWS | GCP |
+|---|---|---|
+| write | `secretsmanager create-secret` / `update-secret` | `gcloud secrets create` / `versions add` |
+| read | `secretsmanager get-secret-value` | `gcloud secrets versions access latest` |
+| CLI prefix | `get_aws_cmd()` | project-scoped `gcloud` |
+
+`--region` / `--profile` stay AWS-only and `--project` is GCP-only; passing one
+to the wrong cloud must fail at argument parsing, not at the API call.
+
+### Secret naming — a constraint that forces a rename
+
+AWS secret names are paths: `certificates/priv.aws.ogenki.io/root-ca`.
+**GCP Secret Manager secret IDs permit only letters, digits, `-` and `_`** — no
+slashes, no dots. Every name has to be rewritten; the two clouds cannot share one
+convention. Following the `flux-github-app` precedent already in the GCP tree:
+
+| Secret | Contents |
+|---|---|
+| `openbao-priv-gcp-intermediate-ca` | intermediate certificate **+ key** |
+| `openbao-priv-gcp-server-cert` | OpenBao's leaf, EC P-256 |
+| `openbao-priv-gcp-ca-chain` | root + intermediate **certificates only** — public, what clients trust |
+| `openbao-priv-gcp-root-token` | written by `openbao-config.sh init` |
+| `openbao-priv-gcp-recovery-keys` | written by `openbao-config.sh init` |
+
+The domain's dots are dropped rather than encoded: `priv-gcp-ogenki-io` adds
+length without disambiguating anything in a single-domain project.
+
+**No root-CA secret exists on GCP.** Its absence is the design.
+
+## How GKE consumes it
+
+External Secrets pulls the AppRole credentials and the CA chain from GCP Secret
+Manager. cert-manager's `ClusterIssuer` points at `bao.priv.gcp.ogenki.io:8200`.
+A `Certificate` resource proves the chain end to end.
+
+### A dependency on slice 5
+
+External Secrets needs to read GCP Secret Manager, which means a Google identity
+— a `GCPWorkloadIdentity` claim. But the IAM condition in
+[`opentofu/gcp/gke/init/iam.tf`](../../../opentofu/gcp/gke/init/iam.tf)
+allowlists **only** `xplane_dns_editor`. A claim requesting Secret Manager access
+is refused at the provider.
+
+So this workstream requires a second pre-created custom role — `xplane_secret_reader`,
+holding `secretmanager.versions.access` — added to `crossplane_grantable_roles`.
+
+That is the mechanism working as intended, not an obstacle: adding a capability
+is a deliberate act in OpenTofu, and a claim cannot grant itself one.
+
+**This role is project-wide, and that is the weaker of two options.**
+`GCPWorkloadIdentity` renders `ProjectIAMMember`, so any principal holding
+`xplane_secret_reader` can read *any* Secret Manager secret in the project by
+name — including `openbao-priv-gcp-root-token`,
+`openbao-priv-gcp-recovery-keys`, `openbao-priv-gcp-intermediate-ca` (cert and
+key), and `flux-github-app`, all named a few sections up. Restricting the role
+to `versions.access` alone (dropping `.list`/`secrets.get`/`secrets.list`)
+removes enumeration, not name-based read.
+
+The preferred approach, left for Task 8 to apply: bind
+`roles/secretmanager.secretAccessor` **per secret** with
+`google_secret_manager_secret_iam_member` — exactly what
+`opentofu/gcp/openbao/cluster/iam.tf` already does for the OpenBao server
+certificate — scoped to the two secrets External Secrets actually needs
+(`openbao-priv-gcp-approle-cert-manager`, `openbao-priv-gcp-ca-chain`). That
+would make this project-wide grantable role unnecessary. Not done here: the
+per-secret bindings are OpenTofu in the GKE-consuming stack, which Task 8 has
+not written yet, so the decision belongs there rather than in this allowlist.
+
+## Success criteria
+
+Falsifiable, verified against a live cluster.
+
+1. `bao status` against `https://bao.priv.gcp.ogenki.io:8200` reports
+   `Initialized: true`, `Sealed: false`, from a tailnet device.
+2. The node is unsealed **without operator input** after a stop/start — proving
+   the `gcpckms` seal, not a manual unseal.
+3. `openssl s_client` against the endpoint presents a chain that verifies to the
+   **offline root**, and the served leaf's SAN contains the DNS name and no IP.
+4. `gcloud secrets list` shows **no secret containing the root CA private key**.
+5. The `pki_private_issuer` mount's issuer is the openssl-made intermediate:
+   `bao read pki_private_issuer/issuer/default` returns a certificate whose
+   subject matches it, and no OpenBao-generated intermediate exists.
+6. A cert-manager `Certificate` in the GKE cluster reaches `Ready=True`, issued
+   by the ClusterIssuer, with a chain terminating at the offline root.
+7. `terramate script run deploy` for both stacks produces a 0-change plan on a
+   second run.
+8. Teardown removes every billable resource; `gcloud compute instances list` and
+   `gcloud container clusters list` are empty afterwards.
+
+## Risks and open questions
+
+- **Offline root custody is a procedure, not a resource.** The design says the
+  root never touches a networked system, but where it *does* live — encrypted
+  media, a password manager — is an operator decision this document does not
+  make. It must be written down somewhere before the first signing ceremony,
+  or the property is aspirational.
+- **The Secret Manager grant is project-wide until Task 8 narrows it, and only a
+  code comment says so.** `xplane_secret_reader` holds `secretmanager.versions.access`
+  granted through `ProjectIAMMember`, which is project-scoped: any holder that knows
+  a secret's name can read it, including the OpenBao root token, the recovery keys
+  and the intermediate CA private key. The narrower fix — per-secret
+  `google_secret_manager_secret_iam_member` bindings, the pattern the cluster stack
+  already uses for the server certificate — belongs with Task 8, whose stack does not
+  exist yet. That is a real sequencing constraint rather than a shortcut, but it is
+  recorded here as well as in the code because "deferred to Task 8" with nothing
+  tracking it is how documented debt becomes permanent. **If Task 8 is descoped or
+  slips, this grant must be narrowed or removed, not inherited.**
+- **The interim two-anchor state has no deadline.** AWS migrates "later". If
+  that slips indefinitely the platform keeps two trust anchors, which is the
+  outcome this design set out to avoid.
+- **`file` storage on a single node has no backup story here.** The snapshot
+  AppRole was scoped out because GCP has no consumer, but that also means
+  nothing is backing up the PKI. Acceptable while the platform is rebuilt from
+  scratch; not acceptable the moment anything long-lived depends on it.
+- **Untested at design time:** that `config_ca` alone, without the
+  CSR/sign/set-signed sequence, leaves the mount able to issue. This is the
+  standard import-an-existing-CA flow, but it has not been exercised in this
+  repository, and it is the single assumption the chain rests on. Verify it
+  early in implementation rather than at the end.
diff --git a/docs/superpowers/specs/2026-08-25-gcp-openbao-verification.md b/docs/superpowers/specs/2026-08-25-gcp-openbao-verification.md
new file mode 100644
index 000000000..723dac78b
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-25-gcp-openbao-verification.md
@@ -0,0 +1,217 @@
+# OpenBao on GCP — first live deploy, verification and findings
+
+**Date:** 2026-08-25
+**Design:** [`2026-08-24-gcp-openbao-design.md`](./2026-08-24-gcp-openbao-design.md)
+**Plan:** [`../plans/2026-08-24-gcp-openbao.md`](../plans/2026-08-24-gcp-openbao.md)
+**Outcome:** PKI chain proven end to end. Nine findings, five fixed on the branch,
+four recorded here. Torn down to zero billable resources.
+
+## Why this document exists
+
+Four of the plan's eight tasks passed every static gate — `tofu validate`,
+`trivy`, `tflint`, `shellcheck` — plus a per-task review each and a whole-branch
+review that found a Critical security hole. Then the first live deploy found
+**nine more things**, six of which no static analysis could reach.
+
+That ratio is the point. The gates and reviews were not wasted — the
+whole-branch review caught a project-wide IAM grant that fails *open* and would
+never have surfaced in a deploy at all. But a design sentence like *"the instance
+service account needs `cloudkms.cryptoKeyEncrypterDecrypter` and nothing else"*
+can be read by three reviewers, restated in a plan, implemented faithfully, and
+still be false.
+
+## What was proven
+
+| Design criterion | Result |
+|---|---|
+| 2 — unsealed **without operator input** after init | **PASS** — `Sealed: false`, `Recovery Seal Type: gcpckms` |
+| 3 — chain verifies to the **offline root**; leaf SAN has DNS and no IP | **PASS** — `Verify return code: 0 (ok)` |
+| 8 — teardown removes every billable resource | **PASS** — 25 destroyed, 0 instances/networks/rules remain |
+
+Plus three things the design assumed but had never exercised:
+
+- **`config_ca` alone leaves the mount able to issue.** The design deletes four
+  resources (`key` → `intermediate_cert_request` → `root_sign_intermediate` →
+  `set_signed`) on this assumption and flagged it as the single untested premise
+  the chain rests on. Probed directly: importing the openssl-made intermediate
+  produced both an issuer and a key, a role issued a leaf, and that leaf verified
+  to the offline root. **The premise holds.**
+- **`openbao-config.sh --cloud gcp` works end to end** — waited for readiness,
+  initialised, created both Secret Manager secrets, and reported the server
+  initialised, unsealed and active.
+- **The pinned OpenBao GPG fingerprint verifies on a real boot**
+  (`66D1 5FDD 8728 7219 C8E1 5478 D200 CD70 2853 E6D0`), and the Secret Manager
+  fetch works under a binding scoped to one secret.
+
+## Findings
+
+### 1. The `gcpckms` seal needs `cloudkms.cryptoKeys.get` — FIXED (`77d7fcef`)
+
+The design said `roles/cloudkms.cryptoKeyEncrypterDecrypter` **"and nothing
+else"**. That is false. OpenBao's `gcpckms` seal verifies the key *exists* before
+using it, and encrypterDecrypter grants encrypt/decrypt without `cryptoKeys.get`:
+
+```
+Error configuring seal "gcpckms": error checking key existence:
+PermissionDenied: Permission 'cloudkms.cryptoKeys.get' denied on resource
+.../cryptoKeys/openbao-unseal (or it may not exist).
+```
+
+Fixed by binding `roles/cloudkms.viewer` at the crypto-key level — the
+least-privileged predefined role carrying that permission, scoped so it sees one
+key.
+
+**The failure mode is the quiet one.** The seal is configured *after* the process
+starts, so the instance reaches `RUNNING`, joins the MIG and reports healthy
+while `openbao.service` crashloops. With no health check at the time, nothing
+surfaced it but the serial console.
+
+### 2. Cloud KMS API is not enabled on a fresh project — FIXED (`e1df0880`)
+
+`gcloud kms keyrings create` fails with `PERMISSION_DENIED`, which reads as an
+IAM problem. gcloud offers to enable the API interactively, but the prompt
+**defaults to no**, so a non-interactive run just fails. Neither the design nor
+the plan mentioned it; now in `kms.tf`'s bootstrap comment.
+
+### 3. Enabling that API and applying immediately still fails — RECORDED
+
+Separate from finding 2 and more confusing. After `gcloud services enable`
+returned success, `keyrings create` worked — so the API looked live — but the
+first `tofu apply` still failed:
+
+```
+Error 403: Google Cloud KMS API has not been used in project ... or it is disabled.
+```
+
+Propagation took several minutes. Anyone hitting only this would reasonably
+conclude their `services enable` had not worked and re-run it. **Wait, then
+apply.**
+
+### 4. systemd gives up permanently after three rapid failures — OPEN
+
+```
+openbao.service: Start request repeated too quickly.
+```
+
+Once the start limit trips, the service never retries — even after the
+underlying cause is fixed. Combined with the MIG having **no
+`auto_healing_policies`** (deferred to Task 6 and still not added), a transient
+IAM or network problem at boot leaves a permanently dead service on a `RUNNING`
+instance that nothing recycles.
+
+**Follow-up:** add `auto_healing_policies` to the MIG using the health check
+Task 6 introduced.
+
+### 5. `recreate-instances` returned SUCCESS without recreating anything — RECORDED
+
+```
+gcloud compute instance-groups managed recreate-instances ... → STATUS: SUCCESS
+```
+
+The MIG then reported `isStable: true` and `versionTarget.isReached: true`, and
+the instance kept its original creation timestamp. Nothing was recreated.
+Deleting the instance directly was what actually forced a rebuild. Treat that
+command's SUCCESS as "request accepted", not "instance replaced" — verify by
+creation timestamp.
+
+### 6. An INTERNAL backend service requires `CONNECTION` balancing mode — FIXED (`2ec60d19`)
+
+The provider defaults a backend to `UTILIZATION`, which GCP rejects:
+
+```
+Error 400: Invalid value for field 'resource.backends[0].balancingMode':
+'UTILIZATION'. Balancing mode must be CONNECTION for an INTERNAL backend service.
+```
+
+Passthrough load balancers distribute connections, not requests, so there is no
+utilization signal. Not guessable from the field name; the error is recorded
+verbatim in `load_balancer.tf`.
+
+### 7. The network stack's split-DNS is EMPTY on first apply — FIXED (`f9222ed8`)
+
+`opentofu/gcp/network/tailscale.tf` creates
+`tailscale_dns_split_nameservers.gcp_private` from
+`data.google_compute_addresses.dns_inbound`, filtered on `purpose = "DNS_RESOLVER"`
+with a `depends_on` on the inbound DNS policy. But `depends_on` on a data source
+does not guarantee the policy has finished *allocating its address*. After a
+first apply:
+
+```
+resource "tailscale_dns_split_nameservers" "gcp_private" {
+    domain      = "priv.gcp.ogenki.io"
+    nameservers = []          # EMPTY
+}
+```
+
+The deploy reports success and **no tailnet client can resolve anything under
+`priv.gcp.ogenki.io`**. A second apply populates it (`["10.10.0.2"]`) because the
+address now exists.
+
+This is a pre-existing bug in the network stack, not introduced by the OpenBao
+work — but it blocks reaching OpenBao, so it belongs to this workstream now.
+Verified the VPC side was never at fault: querying the resolver directly
+(`dig @10.10.0.2 bao.priv.gcp.ogenki.io`) returned the right address throughout.
+
+**Fixed** with two changes, the second mattering more than the first: a 60s
+`time_sleep` between the policy and the data read (the same `hashicorp/time`
+provider the AWS llm-platform stack already uses for EFS mount-target
+propagation), and a `precondition` asserting the address list is non-empty. A
+fixed wait alone would still degrade to the original bug on a slow allocation —
+a successful apply configuring no resolver. The precondition turns that silent
+failure into a loud one naming the consequence, recoverable by re-running.
+
+Not verified against a live first apply: proving it needs another full network
+build and teardown. The precondition means the untested path now fails loudly
+rather than silently, which is the property that was missing.
+
+### 8. The root-token secret's shape is `{"token": …}` — RECORDED
+
+Not `{"root_token": …}`. A probe using the wrong key and a `// .` fallback
+silently produced the entire JSON blob as the token, which surfaced as
+`configured Vault token contains non-printable characters` — an error that says
+nothing about the actual mistake. Anything reading that secret should use
+`jq -r '.token'`.
+
+### 9. A stale Tailscale search domain — PRE-EXISTING, not blocking
+
+`tailscale dns status` lists `priv.gcp.cloud.ogenki.io`, the domain from before
+[ADR-0017](../../../website/content/docs/decisions/0017-multi-cloud-dns-naming.md)
+renamed it. The split *route* is keyed correctly to `priv.gcp.ogenki.io`, so this
+is cosmetic today — but it lives in the tailnet-wide config owned by
+`shared/tailscale`, which the rename never reached.
+
+## Still unverified
+
+- **Criterion 6** — a cert-manager `Certificate` reaching `Ready=True` in GKE.
+  Needs Tasks 7 and 8 and a running cluster; not attempted.
+- **Criterion 7** — a second `terramate script run deploy` producing a 0-change
+  plan. Not tested; the deploy was amended several times mid-flight.
+- **Criterion 5** in its real form — the probe used a throwaway `pki_test` mount,
+  not the `pki_private_issuer` mount the management stack will create.
+- The **management stack (Task 7) does not exist yet**, nor the GKE wiring
+  (Task 8).
+
+## Housekeeping
+
+**The root CA private key is at `~/gcp-openbao-pki-ceremony/root-ca-key.pem`.**
+The operator has confirmed a safe copy exists elsewhere. The local copy is the
+last step of the ceremony and is deliberately left for a human to remove:
+
+```bash
+shred -u ~/gcp-openbao-pki-ceremony/{root-ca-key,intermediate-ca-key,server-key}.pem
+```
+
+Do not delete it without confirming the offline copy — it is the only thing that
+can sign AWS's intermediate when that migration happens.
+
+**Two Secret Manager entries are now stale**:
+`openbao-priv-gcp-root-token` and `openbao-priv-gcp-recovery-keys` belong to a
+destroyed server. They are inert, and `init` overwrites them on the next
+rebuild — but anything reading them in between gets credentials for nothing. The
+three PKI secrets (`intermediate-ca`, `server-cert`, `ca-chain`) are genuinely
+reusable and should stay.
+
+**The KMS key ring and key survive by design.** GCP cannot delete a key ring, and
+a crypto key's deletion only schedules its versions for destruction — which is
+exactly why they are a bootstrap prerequisite rather than stack-managed. They
+cost nothing idle. Do not treat them as a teardown leak.
diff --git a/opentofu/gcp/gke/init/iam.tf b/opentofu/gcp/gke/init/iam.tf
index 587c6ab45..5d20317e2 100644
--- a/opentofu/gcp/gke/init/iam.tf
+++ b/opentofu/gcp/gke/init/iam.tf
@@ -101,10 +101,51 @@ resource "google_project_iam_custom_role" "crossplane_dns" {
   ]
 }
 
+# The Secret Manager role External Secrets is permitted to receive.
+#
+# Pre-created for the same reason as crossplane_dns: `hasOnly` matches exact
+# role names, so a role the composition names at render time can never be
+# allowlisted. Deterministic name, therefore allowlistable.
+#
+# `secretmanager.versions.access` ONLY. Not `.list`/`secrets.get`/`secrets.list`
+# either: ESO's `gcpsm` provider needs only `versions.access` to read a NAMED
+# secret, which is how the GCP OpenBao workstream's ExternalSecrets are written
+# (docs/superpowers/plans/2026-08-24-gcp-openbao.md, Task 8 — two named
+# ExternalSecrets, not `dataFrom.find`). The three dropped permissions are what
+# `find` needs to enumerate; removing them removes the ability to discover
+# secret names, not just to write/delete them.
+#
+# HONEST CAVEAT — what this role does NOT close: `ProjectIAMMember` is
+# PROJECT-SCOPED (see opentofu/gcp/gke/init/iam.tf's file header). A holder of
+# this role, once granted, can read ANY secret in the project by name — root
+# tokens, recovery keys, the intermediate CA private key, flux-github-app — the
+# same names this design documents in the plan. Scoping stops at "no
+# enumeration"; it does not stop "knows the name, reads the secret".
+#
+# The better fix, left for whoever implements Task 8: bind
+# `roles/secretmanager.secretAccessor` PER SECRET via
+# `google_secret_manager_secret_iam_member`, exactly as
+# opentofu/gcp/openbao/cluster/iam.tf already does for the server-certificate
+# secret. That makes this project-wide grantable role unnecessary for Task 8's
+# two secrets. Not done here because Task 8 is not written yet and per-secret
+# bindings are OpenTofu resources in the GKE-consuming stack, not something
+# this allowlist can express — the decision belongs with that task.
+resource "google_project_iam_custom_role" "crossplane_secret_reader" {
+  project     = var.project_id
+  role_id     = "xplane_secret_reader"
+  title       = "Crossplane Secret Manager reader"
+  description = "Read named secret VERSIONS for External Secrets. No list/enumerate, no create, no delete; still project-wide by name — see opentofu/gcp/gke/init/iam.tf."
+
+  permissions = [
+    "secretmanager.versions.access",
+  ]
+}
+
 locals {
   # Roles Crossplane may grant. Keep tight; grow on evidence.
   crossplane_grantable_roles = [
     google_project_iam_custom_role.crossplane_dns.name,
+    google_project_iam_custom_role.crossplane_secret_reader.name,
   ]
 
   # TRAP 1, and it is silent: `projects/` takes the project NUMBER while
diff --git a/opentofu/gcp/network/tailscale.tf b/opentofu/gcp/network/tailscale.tf
index e263efe16..92dbeae9f 100644
--- a/opentofu/gcp/network/tailscale.tf
+++ b/opentofu/gcp/network/tailscale.tf
@@ -48,12 +48,30 @@ resource "google_dns_policy" "inbound" {
   }
 }
 
+# `depends_on` alone is NOT enough here, and the failure it produces is silent.
+#
+# Creating the inbound policy RETURNS before GCP has finished allocating the
+# resolver address. `depends_on` defers the data-source read until after the
+# policy resource is created, which is not the same as after the address exists.
+# So on a FIRST apply the filter matches nothing, the list below is empty, and
+# the split nameserver is written with `nameservers = []`.
+#
+# Nothing fails. The apply reports success, and every tailnet client silently
+# cannot resolve *.priv.gcp.ogenki.io -- the VPC resolver is fine, the zone is
+# fine, there is simply no nameserver configured. A SECOND apply fixes it,
+# because by then the address exists. Measured 2026-08-25: first apply produced
+# `nameservers = []`, re-apply produced `["10.10.0.2"]`.
+resource "time_sleep" "dns_inbound_allocation" {
+  depends_on      = [google_dns_policy.inbound]
+  create_duration = "60s"
+}
+
 data "google_compute_addresses" "dns_inbound" {
   project = var.project_id
   region  = var.region
   filter  = "purpose = \"DNS_RESOLVER\""
 
-  depends_on = [google_dns_policy.inbound]
+  depends_on = [time_sleep.dns_inbound_allocation]
 }
 
 # Per-domain, keyed by domain name -> no collision with the AWS split nameservers.
@@ -62,6 +80,17 @@ resource "tailscale_dns_split_nameservers" "gcp_private" {
   # The inbound policy allocates one resolver address per subnet in the region;
   # with a single subnet there is exactly one.
   nameservers = [for a in data.google_compute_addresses.dns_inbound.addresses : a.address]
+
+  # The wait above makes the empty case unlikely; this makes it impossible to
+  # ship silently. Without this, a slow allocation degrades to exactly the
+  # original bug -- a successful apply that configures no resolver at all.
+  # Failing loudly is recoverable: re-run the deploy.
+  lifecycle {
+    precondition {
+      condition     = length(data.google_compute_addresses.dns_inbound.addresses) > 0
+      error_message = "Cloud DNS inbound forwarding allocated no DNS_RESOLVER address yet, so the Tailscale split nameserver would be configured EMPTY and *.${var.private_domain_name} would silently fail to resolve for every tailnet client. The allocation is eventually consistent; re-run the deploy."
+    }
+  }
 }
 
 resource "tailscale_tailnet_key" "this" {
diff --git a/opentofu/gcp/network/versions.tf b/opentofu/gcp/network/versions.tf
index 793ba15d8..3d56cb3cc 100644
--- a/opentofu/gcp/network/versions.tf
+++ b/opentofu/gcp/network/versions.tf
@@ -17,5 +17,11 @@ terraform {
       source  = "tailscale/tailscale"
       version = "~> 0.29"
     }
+    # Only for the inbound-DNS allocation wait in tailscale.tf. Same provider
+    # the AWS llm-platform stack uses for EFS mount-target propagation.
+    time = {
+      source  = "hashicorp/time"
+      version = "~> 0.11"
+    }
   }
 }
diff --git a/opentofu/gcp/openbao/cluster/.trivyignore.yaml b/opentofu/gcp/openbao/cluster/.trivyignore.yaml
new file mode 100644
index 000000000..f5df870d0
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/.trivyignore.yaml
@@ -0,0 +1,10 @@
+# Per-stack ignorefile. The Terramate scripts run
+#   trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+# from the STACK directory, so this file must exist here even when empty --
+# without it trivy exits FATAL "ignore file not found" and the deploy fails
+# before a single resource is planned.
+#
+# Findings in this stack are suppressed with inline `#trivy:ignore:` comments
+# next to the resource they apply to, which keeps the justification with the
+# code. Add ids here only for findings that have no single owning resource.
+misconfigurations: []
diff --git a/opentofu/gcp/openbao/cluster/backend.tf b/opentofu/gcp/openbao/cluster/backend.tf
new file mode 100644
index 000000000..ad539a934
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/backend.tf
@@ -0,0 +1,14 @@
+# State lives in S3, not GCS, even though this stack manages GCP resources.
+# See opentofu/gcp/network/backend.tf for the full rationale.
+#
+# NOTE the hardcoded region. It is the S3 BUCKET's region and has nothing to do
+# with var.region, which in this stack is a GCP region (europe-west4).
+terraform {
+  backend "s3" {
+    bucket       = "demo-smana-remote-backend"
+    key          = "cloud-native-ref/gcp/openbao/cluster/opentofu.tfstate"
+    region       = "eu-west-3"
+    encrypt      = true
+    use_lockfile = true
+  }
+}
diff --git a/opentofu/gcp/openbao/cluster/compute.tf b/opentofu/gcp/openbao/cluster/compute.tf
new file mode 100644
index 000000000..8969a9c0b
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/compute.tf
@@ -0,0 +1,157 @@
+# Single-node OpenBao compute: instance template + a one-instance MIG.
+#
+# This mirrors the AWS stack's "dev" mode, not "ha" (see
+# opentofu/aws/openbao/cluster/README.md) -- one node, `storage "file"`, no
+# raft join, no quorum. This stack is a demo/test posture torn down and
+# rebuilt on every platform test cycle; scaling to a real multi-node raft
+# cluster is future work, not attempted here.
+
+# Ubuntu, not a GCP-native image family such as Container-Optimized OS: the
+# boot script installs OpenBao from a signed .deb via dpkg (scripts/startup-
+# script.sh), which COS's read-only, container-only root filesystem cannot
+# do. Matches the AWS stack, which also boots a Canonical AMI for the same
+# reason.
+data "google_compute_image" "ubuntu" {
+  family  = "ubuntu-2404-lts-amd64"
+  project = "ubuntu-os-cloud"
+}
+
+resource "google_compute_instance_template" "openbao" {
+  name_prefix  = "openbao-${var.env}-"
+  project      = var.project_id
+  region       = var.region
+  machine_type = var.machine_type
+
+  disk {
+    source_image = data.google_compute_image.ubuntu.self_link
+    auto_delete  = true
+    boot         = true
+    disk_type    = "pd-balanced"
+    # OS + the OpenBao .deb + snap-installed gcloud CLI + logs. Generous on
+    # purpose, and not a variable: this is the same OS/binary set on every
+    # node, with nothing environment-specific to size for.
+    disk_size_gb = 20
+  }
+
+  # OpenBao's storage (file backend) and its TLS material live here, not on
+  # the boot disk -- so a boot disk replacement (a new image, a template
+  # revision) never touches raft/file state. device_name is the contract with
+  # scripts/setup-local-disks.sh, which looks for this disk at the stable path
+  # /dev/disk/by-id/google-openbao-data.
+  #
+  # auto_delete = true, matching the AWS dev launch template's
+  # delete_on_termination = true on its root volume: this is a single-node,
+  # torn-down-every-cycle demo posture, not a deployment with anything on the
+  # data disk worth outliving the instance. Revisit before any real HA/raft
+  # work, which will need a disk that survives instance replacement.
+  disk {
+    auto_delete  = true
+    boot         = false
+    disk_type    = "pd-balanced"
+    disk_size_gb = var.data_disk_size_gb
+    device_name  = "openbao-data"
+  }
+
+  network_interface {
+    subnetwork = local.subnetwork_self_link
+    # No access_config => no external IP. Matches the network stack's other
+    # GCE workload (the Tailscale subnet router): egress goes through Cloud
+    # NAT, ingress arrives over the tailnet / internal load balancer (Task 6).
+  }
+
+  service_account {
+    email = google_service_account.openbao.email
+    # Broad OAuth scope, narrow IAM: the actual permissions are the two grants
+    # in iam.tf (KMS encrypt/decrypt on one key, Secret Manager access on one
+    # secret), not this scope. Same pattern as the Tailscale subnet router in
+    # opentofu/gcp/network/tailscale.tf.
+    scopes = ["cloud-platform"]
+  }
+
+  # Measured boot, kernel-signature verification and a virtual TPM. Cheap to
+  # enable on the Ubuntu UEFI image and worth it here: this instance holds the
+  # OpenBao unseal path and the private PKI's server key material.
+  shielded_instance_config {
+    enable_secure_boot          = true
+    enable_vtpm                 = true
+    enable_integrity_monitoring = true
+  }
+
+  metadata = {
+    # OS Login keeps SSH access on IAM rather than on instance metadata keys.
+    enable-oslogin = "TRUE"
+    # Belt and braces: OS Login already supersedes metadata keys, but blocking
+    # project-wide keys explicitly means a key added at project level can
+    # never grant shell on this instance.
+    block-project-ssh-keys = "TRUE"
+  }
+
+  # setup-local-disks.sh MUST run before startup-script.sh: OpenBao's config
+  # (written by the latter) points storage.path at the mount the former
+  # creates.
+  metadata_startup_script = join("\n", [
+    templatefile("${path.module}/scripts/setup-local-disks.sh", {
+      openbao_data_path = var.openbao_data_path
+    }),
+    templatefile("${path.module}/scripts/startup-script.sh", {
+      openbao_version         = var.openbao_version
+      openbao_data_path       = var.openbao_data_path
+      project_id              = var.project_id
+      region                  = var.region
+      kms_key_ring            = data.google_kms_key_ring.openbao.name
+      kms_crypto_key          = data.google_kms_crypto_key.openbao.name
+      server_cert_secret_name = var.server_cert_secret_name
+      fqdn                    = local.fqdn
+    }),
+  ])
+
+  labels = {
+    app         = "openbao"
+    environment = var.env
+  }
+
+  lifecycle {
+    create_before_destroy = true
+  }
+}
+
+resource "google_compute_instance_group_manager" "openbao" {
+  name               = "openbao-${var.env}"
+  project            = var.project_id
+  zone               = var.zone
+  base_instance_name = "openbao-${var.env}"
+
+  # Single node -- see the file-header note on why this stack does not run
+  # raft/HA. Task 6's backend service (a regional internal load balancer)
+  # points at this resource's `instance_group` attribute.
+  target_size = 1
+
+  version {
+    instance_template = google_compute_instance_template.openbao.id
+  }
+
+  named_port {
+    name = "https"
+    port = 8200
+  }
+
+  # Without this, GCP's default OPPORTUNISTIC update policy applies: the MIG
+  # adopts a new instance_template but does not replace the running instance.
+  # A `tofu apply` that bumps var.openbao_version or edits either boot script
+  # would report success while the node keeps running the OLD template
+  # indefinitely -- there is no second apply, no drift signal, nothing. AWS
+  # hit the analogous trap on its launch template (see
+  # opentofu/aws/openbao/cluster/autoscaling_group.tf around
+  # `update_default_version = true`); this is the MIG-shaped fix for the same
+  # failure mode.
+  #
+  # max_surge_fixed = 0 because this is a single-node MIG (target_size = 1):
+  # there is no second node to surge onto, so the replacement must free the
+  # one slot before creating its successor.
+  update_policy {
+    type                  = "PROACTIVE"
+    minimal_action        = "REPLACE"
+    max_unavailable_fixed = 1
+    max_surge_fixed       = 0
+  }
+}
diff --git a/opentofu/gcp/openbao/cluster/data.tf b/opentofu/gcp/openbao/cluster/data.tf
new file mode 100644
index 000000000..59c6f70e5
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/data.tf
@@ -0,0 +1,13 @@
+# The network stack owns the VPC, subnet, Cloud DNS private zone and Tailscale
+# subnet router. Consuming its state keeps one source of truth for the values
+# this stack builds the OpenBao FQDN and node placement from.
+data "terraform_remote_state" "network" {
+  backend = "s3"
+
+  config = {
+    bucket = "demo-smana-remote-backend"
+    key    = "cloud-native-ref/gcp/network/opentofu.tfstate"
+    # The S3 bucket's region, NOT var.region — see backend.tf.
+    region = "eu-west-3"
+  }
+}
diff --git a/opentofu/gcp/openbao/cluster/dns.tf b/opentofu/gcp/openbao/cluster/dns.tf
new file mode 100644
index 000000000..39f5d51b3
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/dns.tf
@@ -0,0 +1,15 @@
+# The A record clients actually use.
+#
+# This is not cosmetic. OpenBao's server certificate carries
+# DNS:bao.priv.gcp.ogenki.io and NO IP SAN, deliberately, so a client connecting
+# to the load balancer's address by IP cannot verify TLS. The name is the only
+# way in -- which is why this record and the certificate's SAN have to agree
+# exactly, and why local.fqdn derives both.
+resource "google_dns_record_set" "openbao" {
+  project      = var.project_id
+  managed_zone = local.network.private_dns_zone_name
+  name         = "${local.fqdn}."
+  type         = "A"
+  ttl          = 60
+  rrdatas      = [google_compute_address.openbao.address]
+}
diff --git a/opentofu/gcp/openbao/cluster/firewall.tf b/opentofu/gcp/openbao/cluster/firewall.tf
new file mode 100644
index 000000000..b52f649d6
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/firewall.tf
@@ -0,0 +1,62 @@
+# Google's health-check probers. Without this the backend service marks every
+# instance UNHEALTHY and the forwarding rule blackholes traffic -- with no error
+# anywhere except the backend's health status, which nothing surfaces unless you
+# go looking.
+#
+# These two ranges are fixed and documented by Google; they are not our network.
+resource "google_compute_firewall" "openbao_health_check" {
+  name    = "openbao-${var.env}-health-check"
+  project = var.project_id
+  network = local.network.network_self_link
+
+  allow {
+    protocol = "tcp"
+    ports    = ["8200"]
+  }
+
+  source_ranges           = ["130.211.0.0/22", "35.191.0.0/16"]
+  target_service_accounts = [google_service_account.openbao.email]
+}
+
+# Clients reach OpenBao over the tailnet, whose routes the subnet router
+# advertises. Scoped to the advertised ranges rather than the whole VPC: the
+# GKE nodes are in this network too, and they have no business talking to
+# OpenBao's API directly -- their access is via cert-manager, which comes
+# through the same tailnet path.
+resource "google_compute_firewall" "openbao_api" {
+  name    = "openbao-${var.env}-api"
+  project = var.project_id
+  network = local.network.network_self_link
+
+  allow {
+    protocol = "tcp"
+    ports    = ["8200"]
+  }
+
+  source_ranges           = local.network.advertised_routes
+  target_service_accounts = [google_service_account.openbao.email]
+}
+
+# IAP TCP forwarding for SSH, OFF by default.
+#
+# This is the "how do you reach a node whose boot script failed" path. It is
+# disabled because the tailnet already reaches the subnet and an always-on admin
+# path is a standing exposure. Turn it on for a debugging session, turn it off
+# after -- and note that on 2026-08-25 the thing that actually needed debugging
+# (a crashlooping openbao.service) was diagnosed entirely from the serial
+# console, which needs no firewall rule at all.
+resource "google_compute_firewall" "openbao_iap_ssh" {
+  count = var.enable_iap_ssh ? 1 : 0
+
+  name    = "openbao-${var.env}-iap-ssh"
+  project = var.project_id
+  network = local.network.network_self_link
+
+  allow {
+    protocol = "tcp"
+    ports    = ["22"]
+  }
+
+  source_ranges           = ["35.235.240.0/20"]
+  target_service_accounts = [google_service_account.openbao.email]
+}
diff --git a/opentofu/gcp/openbao/cluster/iam.tf b/opentofu/gcp/openbao/cluster/iam.tf
new file mode 100644
index 000000000..46bfe2cd2
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/iam.tf
@@ -0,0 +1,56 @@
+resource "google_service_account" "openbao" {
+  account_id   = "openbao-${var.env}"
+  display_name = "OpenBao node"
+  project      = var.project_id
+}
+
+# Unseal. Not admin on the key. Bound to the data source in kms.tf, not a
+# managed resource -- the key ring and key are a bootstrap prerequisite (see
+# kms.tf for why).
+#
+# TWO roles are required, and the second is not obvious. The design said
+# encrypterDecrypter "and nothing else"; that is wrong, and only a live boot
+# showed it:
+#
+#   Error configuring seal "gcpckms": error checking key existence:
+#   PermissionDenied: Permission 'cloudkms.cryptoKeys.get' denied on resource
+#   .../cryptoKeys/openbao-unseal (or it may not exist).
+#
+# OpenBao's gcpckms seal checks the key EXISTS before using it, and
+# cryptoKeyEncrypterDecrypter grants encrypt/decrypt without cryptoKeys.get.
+# roles/cloudkms.viewer is the least-privileged predefined role that carries it,
+# and bound at the crypto-key level it sees only this one key.
+#
+# The failure is quiet in the worst way: the instance reaches RUNNING and joins
+# the MIG while openbao.service crashloops, because the seal is configured
+# AFTER the process starts. Measured 2026-08-25.
+resource "google_kms_crypto_key_iam_member" "openbao_unseal" {
+  crypto_key_id = data.google_kms_crypto_key.openbao.id
+  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
+  member        = "serviceAccount:${google_service_account.openbao.email}"
+}
+
+resource "google_kms_crypto_key_iam_member" "openbao_key_get" {
+  crypto_key_id = data.google_kms_crypto_key.openbao.id
+  role          = "roles/cloudkms.viewer"
+  member        = "serviceAccount:${google_service_account.openbao.email}"
+}
+
+# Read the server certificate at boot. Scoped to that ONE secret -- not
+# project-wide secretAccessor, which would let the node read Flux's GitHub App
+# credentials and every other secret in the project.
+#
+# var.server_cert_secret_name names a secret created by a different task (the
+# PKI/certificate task, plan Task 3 -- the offline ceremony that loads Secret
+# Manager). The real constraint is ordering, not that this stack never
+# applies: Task 3's secret must exist in GCP Secret Manager BEFORE this stack
+# is applied, or the instance's boot script (startup-script.sh) fails to fetch
+# a certificate that isn't there yet. This binding itself only references the
+# secret by name/IAM policy, which OpenTofu can create either order -- it is
+# the runtime fetch at boot that enforces Task 3 -> this stack.
+resource "google_secret_manager_secret_iam_member" "openbao_server_cert" {
+  project   = var.project_id
+  secret_id = var.server_cert_secret_name
+  role      = "roles/secretmanager.secretAccessor"
+  member    = "serviceAccount:${google_service_account.openbao.email}"
+}
diff --git a/opentofu/gcp/openbao/cluster/kms.tf b/opentofu/gcp/openbao/cluster/kms.tf
new file mode 100644
index 000000000..e92471bc4
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/kms.tf
@@ -0,0 +1,54 @@
+# Auto-unseal key. Looked up by name, NOT managed here.
+#
+# NOT because `tofu destroy` would fail on them -- it wouldn't. The google
+# provider's delete for both `google_kms_key_ring` and `google_kms_crypto_key`
+# is a NO-OP: it removes the object from OpenTofu state and returns success
+# without calling any GCP delete API (there mostly isn't one -- key rings
+# cannot be deleted at all, and a crypto key's "deletion" only schedules its
+# versions for destruction). A destroy of a stack that managed them directly
+# would exit 0 just like this one does.
+#
+# The real reasons they are out-of-band data sources instead:
+#
+#   - CREATE breaks on rebuild. The no-op delete above means the key ring
+#     still exists server-side after a "successful" destroy. The NEXT
+#     `tofu apply`'s `google_kms_key_ring` resource block would try to CREATE
+#     it again and fail with ALREADY_EXISTS -- a managed resource has no
+#     "adopt if present" mode.
+#   - DESTROY is a silent trap, not a loud one. If `google_kms_crypto_key`
+#     WERE managed here, `tofu destroy` would call the provider's delete,
+#     which schedules that key's VERSIONS for destruction -- and because the
+#     call still returns success (see above), the run exits 0 while quietly
+#     scheduling destruction of the unseal key every sealed OpenBao instance
+#     depends on. Nothing in the exit code or the destroy script's tolerance
+#     policy (workflows.tm.hcl) would flag it.
+#
+# Re-testing "does `tofu destroy` fail on these" and finding that it doesn't
+# is not evidence the bootstrap step is unnecessary -- it is exactly the
+# no-op behavior this comment describes. The failure these two points guard
+# against shows up on the NEXT apply (ALREADY_EXISTS) or silently in Cloud KMS
+# version state (scheduled destruction), not in this stack's own exit code.
+#
+# So the key ring and key are created ONCE, out of band, as a bootstrap
+# prerequisite -- exactly like the S3 state bucket (see backend.tf) -- and
+# this stack only reads them:
+#
+#   # The API is NOT enabled by default on a fresh project. Without this the
+#   # keyring create fails with PERMISSION_DENIED and an interactive prompt that
+#   # defaults to "no" -- measured 2026-08-25 on ogenki-435905.
+#   gcloud services enable cloudkms.googleapis.com --project ogenki-435905
+#   gcloud kms keyrings create openbao-dev --location europe-west4 --project ogenki-435905
+#   gcloud kms keys create openbao-unseal --location europe-west4 --keyring openbao-dev --purpose encryption --project ogenki-435905
+#
+# The instance service account gets encrypter/decrypter on the key and nothing
+# else (iam.tf) -- it never needs to manage the key, only use it.
+data "google_kms_key_ring" "openbao" {
+  name     = var.kms_key_ring_name
+  project  = var.project_id
+  location = var.region
+}
+
+data "google_kms_crypto_key" "openbao" {
+  name     = var.kms_crypto_key_name
+  key_ring = data.google_kms_key_ring.openbao.id
+}
diff --git a/opentofu/gcp/openbao/cluster/load_balancer.tf b/opentofu/gcp/openbao/cluster/load_balancer.tf
new file mode 100644
index 000000000..f4d4d4482
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/load_balancer.tf
@@ -0,0 +1,67 @@
+# Internal passthrough Network LB fronting the OpenBao MIG.
+#
+# Passthrough (not a proxy) is deliberate: OpenBao terminates TLS itself with a
+# certificate issued by the offline root, and a proxying LB would either need
+# that private CA in its trust store or terminate TLS with its own certificate.
+# A passthrough LB forwards the TCP stream untouched, so the client verifies
+# OpenBao's own certificate end to end.
+resource "google_compute_address" "openbao" {
+  name         = "openbao-${var.env}"
+  project      = var.project_id
+  region       = var.region
+  subnetwork   = local.subnetwork_self_link
+  address_type = "INTERNAL"
+  purpose      = "GCE_ENDPOINT"
+}
+
+# TCP, not HTTPS. An HTTPS health check would have to trust the private CA, and
+# the check runs from Google's probers, which have no way to be given it. TCP
+# proves the listener is accepting connections, which is what the LB needs to
+# decide whether to send traffic; whether OpenBao is sealed is a different
+# question and one the LB should not answer -- a sealed node still needs to be
+# reachable so an operator can unseal it.
+resource "google_compute_health_check" "openbao" {
+  name                = "openbao-${var.env}"
+  project             = var.project_id
+  check_interval_sec  = 10
+  timeout_sec         = 5
+  healthy_threshold   = 2
+  unhealthy_threshold = 3
+
+  tcp_health_check {
+    port = 8200
+  }
+}
+
+resource "google_compute_region_backend_service" "openbao" {
+  name                  = "openbao-${var.env}"
+  project               = var.project_id
+  region                = var.region
+  load_balancing_scheme = "INTERNAL"
+  protocol              = "TCP"
+  health_checks         = [google_compute_health_check.openbao.id]
+
+  # CONNECTION is not a tuning choice — an INTERNAL backend service rejects the
+  # provider's default UTILIZATION outright:
+  #   Error 400: Invalid value for field 'resource.backends[0].balancingMode':
+  #   'UTILIZATION'. Balancing mode must be CONNECTION for an INTERNAL backend
+  #   service.
+  # Passthrough load balancers distribute connections, not requests, so there is
+  # no utilization signal for them to balance on.
+  backend {
+    group          = google_compute_instance_group_manager.openbao.instance_group
+    balancing_mode = "CONNECTION"
+  }
+}
+
+resource "google_compute_forwarding_rule" "openbao" {
+  name                  = "openbao-${var.env}"
+  project               = var.project_id
+  region                = var.region
+  load_balancing_scheme = "INTERNAL"
+  ip_protocol           = "TCP"
+  ports                 = ["8200"]
+  ip_address            = google_compute_address.openbao.id
+  subnetwork            = local.subnetwork_self_link
+  backend_service       = google_compute_region_backend_service.openbao.id
+}
diff --git a/opentofu/gcp/openbao/cluster/locals.tf b/opentofu/gcp/openbao/cluster/locals.tf
new file mode 100644
index 000000000..9eba01c9c
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/locals.tf
@@ -0,0 +1,9 @@
+# One name for the network stack's outputs, so this stack does not re-derive
+# values the network stack already owns — the VPC, subnet, Cloud DNS private
+# zone and Tailscale subnet router all live there.
+locals {
+  network = data.terraform_remote_state.network.outputs
+
+  subnetwork_self_link = local.network.nodes_subnetwork_self_link
+  fqdn                 = "bao.${local.network.private_domain_name}"
+}
diff --git a/opentofu/gcp/openbao/cluster/outputs.tf b/opentofu/gcp/openbao/cluster/outputs.tf
new file mode 100644
index 000000000..a0ddeb444
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/outputs.tf
@@ -0,0 +1,19 @@
+output "endpoint" {
+  description = "OpenBao API endpoint. Reachable from the tailnet; TLS verifies only against this NAME, never the IP."
+  value       = "https://${local.fqdn}:8200"
+}
+
+output "fqdn" {
+  description = "OpenBao's DNS name, matching the server certificate's only SAN"
+  value       = local.fqdn
+}
+
+output "internal_ip" {
+  description = "Load balancer address. For diagnostics only -- connecting here by IP cannot verify TLS, by design."
+  value       = google_compute_address.openbao.address
+}
+
+output "service_account_email" {
+  description = "The OpenBao node's service account"
+  value       = google_service_account.openbao.email
+}
diff --git a/opentofu/gcp/openbao/cluster/providers.tf b/opentofu/gcp/openbao/cluster/providers.tf
new file mode 100644
index 000000000..fc74f25a5
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/providers.tf
@@ -0,0 +1,4 @@
+provider "google" {
+  project = var.project_id
+  region  = var.region
+}
diff --git a/opentofu/gcp/openbao/cluster/scripts/setup-local-disks.sh b/opentofu/gcp/openbao/cluster/scripts/setup-local-disks.sh
new file mode 100644
index 000000000..79c57215d
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/scripts/setup-local-disks.sh
@@ -0,0 +1,109 @@
+#!/usr/bin/env bash
+# Formats and mounts the OpenBao data disk. Rendered into the instance's
+# `metadata_startup_script` (compute.tf), concatenated BEFORE startup-script.sh
+# -- the data disk has to be mounted before OpenBao is configured to write its
+# storage there. Runs on every boot, not only the first: the idempotency
+# checks below (skip mkfs if a filesystem already exists, `systemctl enable
+# --now` is itself idempotent) are what make that safe.
+#
+# THIS SCRIPT AND startup-script.sh ARE JOINED INTO ONE metadata_startup_script
+# AND SHARE ONE PROCESS (compute.tf: `join("\n", [templatefile(setup-local-
+# disks.sh, ...), templatefile(startup-script.sh, ...)])`). `set -o errexit`
+# and any bare `exit` in either half therefore terminates the WHOLE combined
+# script, not just its own half -- an `exit 0` here silently skips OpenBao's
+# install/configure/start in startup-script.sh entirely: the instance boots,
+# joins the MIG, reports RUNNING, and serves nothing. That is why the
+# missing-disk branch below is `exit 1`, not `exit 0` -- unlike AWS, where the
+# instance-store disk is genuinely optional scratch space, this stack's data
+# disk is declared by compute.tf and always attached; its absence is a
+# provisioning bug, a hard error, never a state to boot past quietly.
+#
+# Ported from
+# opentofu/aws/openbao/cluster/scripts/setup-local-disks.sh, which discovers
+# and RAID-0s ephemeral NVMe instance store via a udev alias glob, because AWS
+# gives no stable, predictable device path for instance-store disks. GCP does:
+# a persistent disk attached with a fixed `device_name` (compute.tf sets
+# device_name = "openbao-data") always appears at
+# /dev/disk/by-id/google-<device_name>. That removes the whole discovery/RAID
+# step -- there is exactly one disk, at a known path, every boot.
+
+set -o errexit
+set -o pipefail
+set -o nounset
+
+err_report() {
+  echo "Error occurred on line $1: $BASH_COMMAND"
+}
+trap 'err_report $LINENO' ERR
+
+check_command() {
+  local cmd=$1
+  if ! command -v "$cmd" &> /dev/null; then
+    echo "Command not found: $cmd"
+    exit 1
+  fi
+}
+
+# xfsprogs (mkfs.xfs) is NOT on the stock Ubuntu image and must be installed
+# here, before it is needed -- this script runs BEFORE startup-script.sh
+# (compute.tf concatenation order), so an `apt-get install` living only in the
+# latter half is too late for mkfs.xfs below. systemd-analyze/blkid/lsblk come
+# from systemd/util-linux, both base-image packages, so no install is needed
+# for them.
+export DEBIAN_FRONTEND=noninteractive
+apt-get update -qq
+apt-get install -y -qq xfsprogs
+
+check_command mkfs.xfs
+check_command systemd-analyze
+check_command blkid
+check_command lsblk
+
+DATA_DISK="/dev/disk/by-id/google-openbao-data"
+MNT_DIR="${openbao_data_path}"
+
+if [[ ! -e "$DATA_DISK" ]]; then
+  # Hard error, not a skip -- see the file-header note. compute.tf always
+  # attaches this disk; if it is missing, something about the instance
+  # template or the disk attachment is broken, and continuing would boot
+  # OpenBao onto whatever the root filesystem happens to have at
+  # openbao_data_path instead of failing loudly.
+  echo "Data disk $DATA_DISK not found -- this is a hard failure, not optional scratch space (unlike AWS's ephemeral NVMe)"
+  exit 1
+fi
+
+if [[ $(id --user) -ne 0 ]]; then
+  echo "Must be run as root"
+  exit 1
+fi
+
+# Idempotent: only format a disk that has no filesystem yet. A re-run after
+# the unit is already mounted must not reformat a disk holding OpenBao's raft
+# or file storage.
+if [[ -z $(lsblk "$DATA_DISK" -o fstype --noheadings) ]]; then
+  mkfs.xfs "$DATA_DISK"
+fi
+
+mkdir -p "$MNT_DIR"
+
+DEV_UUID=$(blkid -s UUID -o value "$DATA_DISK")
+UNIT_NAME="$(systemd-escape --path --suffix=mount "$MNT_DIR")"
+
+cat > "/etc/systemd/system/$UNIT_NAME" << EOF
+[Unit]
+Description=Mount OpenBao data disk at $MNT_DIR
+
+[Mount]
+What=UUID=$DEV_UUID
+Where=$MNT_DIR
+Type=xfs
+Options=defaults,noatime
+
+[Install]
+WantedBy=multi-user.target
+EOF
+
+systemd-analyze verify "$UNIT_NAME"
+systemctl enable "$UNIT_NAME" --now
+
+echo "Successfully mounted $DATA_DISK at $MNT_DIR"
diff --git a/opentofu/gcp/openbao/cluster/scripts/startup-script.sh b/opentofu/gcp/openbao/cluster/scripts/startup-script.sh
new file mode 100644
index 000000000..58e0e9a28
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/scripts/startup-script.sh
@@ -0,0 +1,128 @@
+#!/bin/bash
+# Rendered into the instance's `metadata_startup_script` (compute.tf),
+# concatenated AFTER setup-local-disks.sh -- the data disk must already be
+# mounted before OpenBao is configured to store its data there.
+#
+# NOTHING SECRET MAY BE TEMPLATED INTO THIS FILE. GCP instance metadata is
+# readable from the metadata server (http://metadata.google.internal) by
+# anything running on the box -- a plain unauthenticated HTTP GET with only
+# the `Metadata-Flavor: Google` header, no IAM check gates it -- and via
+# `compute.instances.get`/`getSerializedPortOutput`-equivalent API calls by
+# anything holding that permission. TLS material is fetched from Secret
+# Manager at boot instead, under a service account grant scoped to one secret
+# (see iam.tf).
+
+set -o errexit
+set -o nounset
+set -o pipefail
+
+echo "OpenBao init"
+
+export DEBIAN_FRONTEND=noninteractive
+
+# jq/wget/gnupg are not guaranteed present on the stock Ubuntu image; snapd is,
+# on every Canonical cloud image since 16.04, and is what installs the gcloud
+# CLI below. xfsprogs is installed earlier, in setup-local-disks.sh -- it has
+# to exist before that script's mkfs.xfs runs, which is BEFORE this script
+# (compute.tf concatenation order), so installing it here would be too late.
+apt-get update -qq
+apt-get install -y -qq jq wget gnupg
+
+# Instance identity from the GCP metadata server (IMDS equivalent).
+PRIVATE_IP=$(curl -fsS -H "Metadata-Flavor: Google" \
+  http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip)
+
+# gcloud CLI is not preinstalled on the stock Ubuntu image. Google's apt repo
+# would mean another GPG-verified add-apt-repository dance in the boot path;
+# snapd is already installed and verifies its own packages, so use that --
+# same pattern the AWS script uses for awscli via snap.
+snap wait system seed.loaded
+snap install google-cloud-cli --classic
+export PATH="$PATH:/snap/bin"
+
+# Install OpenBao
+# ---------------
+OPENBAO_VERSION="${openbao_version}"
+OPENBAO_BINARY="openbao_$${OPENBAO_VERSION}_linux_amd64.deb"
+BINARY_URL="https://github.com/openbao/openbao/releases/download/v$OPENBAO_VERSION/$OPENBAO_BINARY"
+SIGNATURE_URL="$BINARY_URL.gpgsig"
+GPG_KEY_URL="https://openbao.org/assets/openbao-gpg-pub-20240618.asc"
+
+# Pinned primary key fingerprint for "OpenBao <openbao@lists.lfedge.org>".
+# Without this the key is fetched fresh on every boot and trusted on sight,
+# which makes the signature check prove only that the key and the binary came
+# from the same place.
+OPENBAO_GPG_FINGERPRINT="66D15FDD87287219C8E15478D200CD702853E6D0" # pragma: allowlist secret
+
+wget -q "$BINARY_URL" -O "$OPENBAO_BINARY"
+wget -q "$SIGNATURE_URL" -O "$OPENBAO_BINARY.gpgsig"
+wget -q "$GPG_KEY_URL" -O openbao-gpg-pub.asc
+
+## Verify the key is the one we expect before importing it
+if ! gpg --show-keys --with-colons openbao-gpg-pub.asc | awk -F: '/^fpr:/{print $10}' | grep -qx "$OPENBAO_GPG_FINGERPRINT"; then
+  echo "OpenBao GPG key fingerprint mismatch - expected $OPENBAO_GPG_FINGERPRINT"
+  exit 1
+fi
+gpg --import openbao-gpg-pub.asc
+
+## Verify the signature
+if ! gpg --verify "$OPENBAO_BINARY.gpgsig" "$OPENBAO_BINARY"; then
+  echo "Signature verification failed!"
+  exit 1
+fi
+echo "Signature verified successfully!"
+
+dpkg -i "$OPENBAO_BINARY"
+
+rm -f "$OPENBAO_BINARY" "$OPENBAO_BINARY.gpgsig" openbao-gpg-pub.asc
+
+# Fetch the server TLS material
+# -----------------------------
+# The `openbao` user and group are created by the .deb, so this has to run
+# after the install.
+install -d -m 0750 -o root -g openbao /opt/openbao/tls
+
+TLS_SECRET=$(gcloud secrets versions access latest \
+  --secret "${server_cert_secret_name}" --project "${project_id}")
+
+umask 077
+printf '%s' "$TLS_SECRET" | jq -r '.cert' > /opt/openbao/tls/tls.crt
+printf '%s' "$TLS_SECRET" | jq -r '.key'  > /opt/openbao/tls/tls.key
+printf '%s' "$TLS_SECRET" | jq -r '.ca'   > /opt/openbao/tls/ca.pem
+unset TLS_SECRET
+
+chown root:openbao /opt/openbao/tls/tls.key
+chmod 0640 /opt/openbao/tls/tls.key
+chmod 0644 /opt/openbao/tls/tls.crt /opt/openbao/tls/ca.pem
+
+# Configure OpenBao
+# -----------------
+chown openbao:openbao /etc/openbao/openbao.hcl
+chown -R openbao:openbao "${openbao_data_path}"
+
+cat << EOF > /etc/openbao/openbao.hcl
+cluster_addr = "https://$PRIVATE_IP:8201"
+api_addr     = "https://${fqdn}:8200"
+ui           = true
+
+listener "tcp" {
+  address         = "[::]:8200"
+  cluster_address = "[::]:8201"
+  tls_cert_file   = "/opt/openbao/tls/tls.crt"
+  tls_key_file    = "/opt/openbao/tls/tls.key"
+}
+
+storage "file" {
+  path = "${openbao_data_path}"
+}
+
+seal "gcpckms" {
+  project    = "${project_id}"
+  region     = "${region}"
+  key_ring   = "${kms_key_ring}"
+  crypto_key = "${kms_crypto_key}"
+}
+EOF
+
+systemctl start openbao.service
+systemctl enable openbao.service
diff --git a/opentofu/gcp/openbao/cluster/stack.tm.hcl b/opentofu/gcp/openbao/cluster/stack.tm.hcl
new file mode 100644
index 000000000..13b9c9db0
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/stack.tm.hcl
@@ -0,0 +1,26 @@
+stack {
+  name        = "GCP OpenBao Cluster"
+  description = "Single-node OpenBao compute (instance template, MIG, boot script) plus its service account/IAM and auto-unseal wiring against a pre-existing Cloud KMS key, ahead of the load balancer and PKI configuration"
+  id          = "d7c24921-dd6c-495d-ab43-db698e2d4724"
+
+  # This stack reads the network stack's outputs via data.terraform_remote_state
+  # (subnet, private DNS zone, domain) -- it must exist first.
+  after = [
+    "/opentofu/gcp/network"
+  ]
+
+  tags = [
+    "gcp",
+    "openbao",
+    "security",
+    # `opt-in` lets `terramate script run --no-tags=opt-in deploy` skip this
+    # stack entirely (CI/audit path). The script overrides in workflows.tm.hcl
+    # additionally guard on $TM_GCP_ENABLED so `terramate script run deploy`
+    # from the opentofu/ root is also safe by default -- the script runs but
+    # no-ops with a [skip] message.
+    #
+    # REMOVE THIS TAG AND THE GUARDS once GCP works end to end. Leaving them on
+    # silently skips GCP forever, which looks identical to success.
+    "opt-in",
+  ]
+}
diff --git a/opentofu/gcp/openbao/cluster/trivy.yaml b/opentofu/gcp/openbao/cluster/trivy.yaml
new file mode 100644
index 000000000..8c24e5d06
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/trivy.yaml
@@ -0,0 +1,11 @@
+# Trivy configuration for the OpenBao cluster OpenTofu stack.
+#
+# Once `tofu init` has downloaded providers into .terraform, a plain
+# `trivy config .` can recurse into that directory. Same problem, same fix, as
+# opentofu/gcp/gke/init/trivy.yaml (which cites the reason in full: vendored
+# module examples full of standalone fixtures trivy would otherwise scan as if
+# they were this stack's own code).
+scan:
+  skip-dirs:
+    # Downloaded Terraform providers
+    - .terraform
diff --git a/opentofu/gcp/openbao/cluster/variables.tf b/opentofu/gcp/openbao/cluster/variables.tf
new file mode 100644
index 000000000..21e55cc26
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/variables.tf
@@ -0,0 +1,95 @@
+variable "project_id" {
+  description = "GCP project ID hosting the OpenBao cluster"
+  type        = string
+}
+
+variable "region" {
+  description = "GCP region"
+  default     = "europe-west4"
+  type        = string
+
+  validation {
+    condition     = can(regex("^[a-z]+-[a-z]+[0-9]+$", var.region))
+    error_message = "Region must be a valid GCP region format (e.g., europe-west4)."
+  }
+}
+
+variable "zone" {
+  description = "GCP zone for the OpenBao instance(s)"
+  default     = "europe-west4-a"
+  type        = string
+
+  validation {
+    condition     = can(regex("^[a-z]+-[a-z]+[0-9]+-[a-z]$", var.zone))
+    error_message = "Zone must be a valid GCP zone format (e.g., europe-west4-a)."
+  }
+}
+
+variable "env" {
+  description = "The environment of the OpenBao cluster"
+  type        = string
+  default     = "dev"
+
+  validation {
+    condition     = contains(["dev", "staging", "prod"], var.env)
+    error_message = "Environment must be one of: dev, staging, prod."
+  }
+}
+
+# Name the bootstrap-created KMS key ring/key (see kms.tf) rather than
+# deriving them from var.env, so a rename of the environment doesn't silently
+# point this stack at a key ring that was never created.
+variable "kms_key_ring_name" {
+  description = "Name of the pre-existing Cloud KMS key ring holding the auto-unseal key. Created out of band -- see kms.tf"
+  type        = string
+  default     = "openbao-dev"
+}
+
+variable "kms_crypto_key_name" {
+  description = "Name of the pre-existing Cloud KMS crypto key used for auto-unseal. Created out of band -- see kms.tf"
+  type        = string
+  default     = "openbao-unseal"
+}
+
+variable "machine_type" {
+  description = "GCE machine type for the OpenBao instance(s)"
+  type        = string
+  default     = "e2-small"
+}
+
+variable "openbao_version" {
+  description = "OpenBao version to install on the instance(s)"
+  type        = string
+  # Kept at the latest release. 2.6.x carries openbao/openbao#3411 (inconsistent
+  # lock ordering across namespaces, mounts and the router, still OPEN), which
+  # deadlocks the core when the management stack writes concurrently — but the
+  # concurrency is ours, not OpenBao's. Mirror the AWS mitigation
+  # (opentofu/aws/openbao/cluster/variables.tf) if the same symptom shows up
+  # here: apply the management stack with -parallelism=1.
+  # renovate: datasource=github-releases depName=openbao/openbao
+  default = "2.6.2"
+}
+
+variable "data_disk_size_gb" {
+  description = "Size in GB of the persistent disk backing OpenBao's file storage backend"
+  type        = number
+  default     = 10
+}
+
+variable "server_cert_secret_name" {
+  description = "Name of the Secret Manager secret holding the OpenBao server certificate. Created by a different task -- see iam.tf"
+  type        = string
+  default     = "openbao-priv-gcp-server-cert"
+}
+
+variable "openbao_data_path" {
+  description = "Path on the instance's data disk where OpenBao's file storage backend keeps its data (single-node, storage \"file\" -- not raft)"
+  type        = string
+  default     = "/opt/openbao/data"
+}
+
+variable "enable_iap_ssh" {
+  description = "Open TCP 22 to Google's IAP forwarding range so an operator can SSH to a node whose boot failed. OFF by default: the tailnet already reaches this subnet, and an always-on admin path is a standing exposure."
+  type        = bool
+  default     = false
+}
diff --git a/opentofu/gcp/openbao/cluster/variables.tfvars b/opentofu/gcp/openbao/cluster/variables.tfvars
new file mode 100644
index 000000000..59a8ce263
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/variables.tfvars
@@ -0,0 +1,6 @@
+# project_id has no default (see variables.tf) -- it must always be supplied.
+# Every other variable is left on its default: region/zone/env match the rest
+# of the GCP stacks, machine_type/data_disk_size_gb/server_cert_secret_name/
+# openbao_data_path/openbao_version are the scaffolding defaults from the
+# design doc (openbao_version tracks the AWS pin -- see variables.tf).
+project_id = "ogenki-435905"
diff --git a/opentofu/gcp/openbao/cluster/versions.tf b/opentofu/gcp/openbao/cluster/versions.tf
new file mode 100644
index 000000000..b201c57c7
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/versions.tf
@@ -0,0 +1,19 @@
+terraform {
+  required_version = "~> 1.5"
+
+  required_providers {
+    google = {
+      source = "hashicorp/google"
+      # Same floor and constraint as every other GCP stack in this repo, to keep
+      # one provider version across network, gke and openbao. See
+      # opentofu/gcp/network/versions.tf for why 7.17 is the floor.
+      version = "~> 7.17"
+    }
+  }
+}
+
+# No google-beta here. Unlike opentofu/gcp/network, this stack consumes no
+# module that declares it -- the KMS key ring/key are read via data source
+# (see kms.tf), and every resource this stack manages (service account, IAM
+# bindings, the instance template, MIG) is a stable google_* resource. Do not
+# add google-beta by reflex; add it only when a resource actually needs it.
diff --git a/opentofu/gcp/openbao/cluster/workflows.tm.hcl b/opentofu/gcp/openbao/cluster/workflows.tm.hcl
new file mode 100644
index 000000000..29dd2ed0d
--- /dev/null
+++ b/opentofu/gcp/openbao/cluster/workflows.tm.hcl
@@ -0,0 +1,192 @@
+# GCP OpenBao cluster — opt-in Terramate scripts.
+#
+# Why override the global scripts (opentofu/workflows.tm.hcl)?
+#   Both clouds share one Terramate run order, so without a guard
+#   `terramate script run deploy` from the opentofu/ root would build this
+#   stack too. The gate keeps that command an AWS one-shot while GCP is
+#   unproven.
+#
+# How the gate works:
+#   $TM_GCP_ENABLED unset or != "true"  -> echo [skip] + exit 0 (success, so
+#                                          sibling stacks are unaffected)
+#   $TM_GCP_ENABLED == "true"           -> run the real sequence
+#
+#   The double-`$$` escape keeps Terramate from interpolating `${VAR:-default}`;
+#   the literal `${...}` must reach bash. `${global.provisioner}` interpolations
+#   are intentional (Terramate-evaluated -> "tofu").
+#
+# Usage:
+#   terramate script run deploy                                   # skipped
+#   TM_GCP_ENABLED=true terramate script run deploy               # runs
+#   terramate script run --no-tags=opt-in deploy                  # skipped, no env var
+#
+# Trade-off: these overrides lose Terramate Cloud sync metadata
+# (sync_deployment / sync_preview), which are command-level annotations that do
+# not compose with a single bash heredoc. Accepted while the gate is temporary;
+# removing the gate restores the global scripts and their cloud sync.
+
+script "deploy" {
+  name        = "GCP OpenBao Cluster Deployment (opt-in)"
+  description = "Deploy the OpenBao cluster stack when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        if [ "$${TM_GCP_ENABLED:-}" != "true" ]; then
+          echo "[skip] GCP OpenBao cluster: set TM_GCP_ENABLED=true to deploy"
+          exit 0
+        fi
+        set -euo pipefail
+        ${global.provisioner} init
+        ${global.provisioner} validate
+        trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+        ${global.provisioner} apply -auto-approve -var-file=variables.tfvars
+      BASH
+      ],
+    ]
+  }
+}
+
+script "preview" {
+  name        = "GCP OpenBao Cluster Preview (opt-in)"
+  description = "Preview OpenBao cluster changes when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        if [ "$${TM_GCP_ENABLED:-}" != "true" ]; then
+          echo "[skip] GCP OpenBao cluster preview: set TM_GCP_ENABLED=true"
+          exit 0
+        fi
+        set -euo pipefail
+        ${global.provisioner} init
+        ${global.provisioner} validate
+        trivy config --exit-code=1 --ignorefile=./.trivyignore.yaml .
+        ${global.provisioner} plan -out=out.tfplan -var-file=variables.tfvars
+      BASH
+      ],
+    ]
+  }
+}
+
+script "drift" "detect" {
+  name        = "GCP OpenBao Cluster Drift Check (opt-in)"
+  description = "Detect drift when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        if [ "$${TM_GCP_ENABLED:-}" != "true" ]; then
+          echo "[skip] GCP OpenBao cluster drift: set TM_GCP_ENABLED=true"
+          exit 0
+        fi
+        set -euo pipefail
+        ${global.provisioner} init
+        ${global.provisioner} plan -out=out.tfplan -detailed-exitcode -lock=false -var-file=variables.tfvars
+      BASH
+      ],
+    ]
+  }
+}
+
+# No tolerance: starting with Task 5 this stack OWNS billable resources -- the
+# OpenBao compute instance(s), load balancer and reserved address. A destroy
+# that swallows failure and exits 0 would let a `terramate script run
+# --reverse destroy` proceed to delete the network stack this one depends on
+# (`after` in stack.tm.hcl), stranding those instances behind a deleted VPC
+# with no workflow path to remove them.
+#
+# This is the mirror image of why opentofu/gcp/gke/configure's destroy IS
+# tolerant: everything that stack manages lives INSIDE the cluster that
+# gke/init deletes moments later, so its failure mode is "nothing left to
+# strand". This stack has no such backstop, so it follows
+# opentofu/gcp/gke/init/workflows.tm.hcl's `stage1-destroy-cluster` job
+# instead: "No tolerance here ... this is the billable resource. If it cannot
+# be destroyed the run must fail loudly rather than move on to the network
+# stack and strand [resources] behind a deleted VPC."
+#
+# The KMS key ring/key are deliberately NOT in this stack's state (see
+# kms.tf: they're a bootstrap prerequisite, read via data source, because
+# GCP can never delete either one). Nothing here blocks a clean destroy on
+# their account, so a failure now genuinely means billable compute survived
+# and this run must stop.
+script "destroy" {
+  name        = "GCP OpenBao Cluster Destroy (opt-in)"
+  description = "Destroy the OpenBao cluster stack when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        if [ "$${TM_GCP_ENABLED:-}" != "true" ]; then
+          echo "[skip] GCP OpenBao cluster destroy: set TM_GCP_ENABLED=true"
+          exit 0
+        fi
+        set -euo pipefail
+        bash "${terramate.root.path.fs.absolute}/scripts/terramate-destroy-confirm.sh"
+        ${global.provisioner} init -lock-timeout=5m
+        # -refresh=false is deliberate on DESTROY: this stack reads the network
+        # stack's outputs through data.terraform_remote_state, and refreshing
+        # that requires the upstream state OBJECT to exist. Once the network
+        # stack has been destroyed its state is empty, so no object is written
+        # at all and the read fails hard with "Unable to find remote state". A
+        # destroy does not need those outputs -- everything being destroyed is
+        # already described by THIS stack's own state.
+        ${global.provisioner} destroy -refresh=false -auto-approve -var-file=variables.tfvars
+      BASH
+      ],
+    ]
+  }
+}
+
+script "init" {
+  name        = "GCP Init (opt-in)"
+  description = "Initialize this GCP stack when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        ${global.gcp_gate}
+        set -euo pipefail
+        ${global.provisioner} init
+      BASH
+      ],
+    ]
+  }
+}
+
+# The global version of this script runs `tofu apply -auto-approve`. Ungated, a
+# drift reconcile from opentofu/ would BUILD this GCP stack without anyone
+# opting in -- which is the whole reason the missing overrides were a problem
+# rather than an inconsistency.
+script "drift" "reconcile" {
+  name        = "GCP Drift Reconciliation (opt-in)"
+  description = "Reconcile drift in this GCP stack when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        ${global.gcp_gate}
+        set -euo pipefail
+        ${global.provisioner} apply -input=false -auto-approve -lock-timeout=5m -var-file=variables.tfvars drift.tfplan
+      BASH
+      ],
+    ]
+  }
+}
+
+script "opentofu" "render" {
+  name        = "GCP Show Plan (opt-in)"
+  description = "Render this GCP stack's plan when TM_GCP_ENABLED=true"
+
+  job {
+    commands = [
+      ["bash", "-c", <<-BASH
+        ${global.gcp_gate}
+        set -euo pipefail
+        echo "Stack: ${terramate.stack.path.absolute}"
+        ${global.provisioner} show -no-color out.tfplan
+      BASH
+      ],
+    ]
+  }
+}
diff --git a/scripts/openbao-config.sh b/scripts/openbao-config.sh
index 5448f8426..ab733acd3 100755
--- a/scripts/openbao-config.sh
+++ b/scripts/openbao-config.sh
@@ -4,7 +4,8 @@ set -euo pipefail
 
 # This script is used to configure OpenBao. It supports two operations:
 # - init: Initialize the OpenBao cluster, then store the root token and the
-#         recovery keys in two SEPARATE AWS Secrets Manager entries
+#         recovery keys in two SEPARATE secret store entries (AWS Secrets
+#         Manager or GCP Secret Manager, selected with --cloud)
 # - ca:   Write the CA chain to a local file so the Vault provider can verify
 #         the server certificate instead of running with skip_tls_verify
 #
@@ -24,7 +25,10 @@ RECOVERY_SHARES=1
 RECOVERY_THRESHOLD=1
 SKIP_VERIFY=false
 REGION="eu-west-3"
+REGION_EXPLICIT=false
 PROFILE=""
+CLOUD="aws"
+PROJECT=""
 
 usage() {
     echo "Usage: $0 <command> [options]"
@@ -34,20 +38,28 @@ usage() {
     echo ""
     echo "Common Options:"
     echo "  --url <OpenBao URL>                       OpenBao server URL (required for init)"
-    echo "  --root-token-secret-name <Secret Name>    AWS Secrets Manager secret for the root token (required for init)"
-    echo "  --recovery-keys-secret-name <Secret Name> AWS Secrets Manager secret for the recovery keys (required for init)"
+    echo "  --root-token-secret-name <Secret Name>    Secret for the root token (required for init)"
+    echo "  --recovery-keys-secret-name <Secret Name> Secret for the recovery keys (required for init)"
     echo "  --recovery-shares <N>                     Number of recovery key shares (default: ${RECOVERY_SHARES})"
     echo "  --recovery-threshold <N>                  Shares needed to reconstruct (default: ${RECOVERY_THRESHOLD})"
-    echo "  --root-ca-secret-name <Secret Name>       AWS Secrets Manager secret holding the CA chain (required for ca)"
+    echo "  --root-ca-secret-name <Secret Name>       Secret holding the CA chain (required for ca)."
+    echo "                                             On AWS this holds JSON with a '.ca' field."
+    echo "                                             On GCP it receives the CA CHAIN secret"
+    echo "                                             (raw PEM) -- by design no root-CA secret"
+    echo "                                             exists on GCP, only the chain."
     echo "  --ca-output-file <Path>                   Where to write the CA chain (required for ca)"
     echo "  --skip-verify                             Skip TLS verification"
     echo "  --region <Region>                         AWS region (default: ${REGION})"
     echo "  --profile <Profile>                       AWS profile"
+    echo "  --cloud <aws|gcp>                         Secret backend (default: aws)"
+    echo "  --project <Project ID>                    GCP project (required for --cloud gcp)"
     echo ""
     echo "Example:"
     echo "  $0 init --url https://openbao:8200 --root-token-secret-name openbao/root-token \\"
     echo "          --recovery-keys-secret-name openbao/recovery-keys"
     echo "  $0 ca --root-ca-secret-name certificates/domain.tld/root-ca --ca-output-file .tls/ca.pem"
+    echo "  $0 ca --cloud gcp --project ogenki-435905 \\"
+    echo "          --root-ca-secret-name openbao-priv-gcp-ca-chain --ca-output-file .tls/ca.pem"
 }
 
 parse_args() {
@@ -61,8 +73,10 @@ parse_args() {
             --root-ca-secret-name)        ROOT_CA_SECRET_NAME="$2"; shift 2 ;;
             --ca-output-file)             CA_OUTPUT_FILE="$2"; shift 2 ;;
             --skip-verify)                SKIP_VERIFY=true; shift ;;
-            --region)                     REGION="$2"; shift 2 ;;
+            --region)                     REGION="$2"; REGION_EXPLICIT=true; shift 2 ;;
             --profile)                    PROFILE="$2"; shift 2 ;;
+            --cloud)                      CLOUD="$2"; shift 2 ;;
+            --project)                    PROJECT="$2"; shift 2 ;;
             *)
                 echo "Invalid argument: $1"
                 usage
@@ -71,6 +85,31 @@ parse_args() {
         esac
     done
 
+    case "$CLOUD" in
+        aws) ;;
+        gcp)
+            if [ -z "$PROJECT" ]; then
+                echo "Error: --project is required with --cloud gcp" >&2
+                exit 1
+            fi
+            # Fail here rather than at the API call: passing an AWS-only flag to
+            # GCP is a mistake about which cloud you are on, and the API error
+            # would not say so.
+            if [ -n "$PROFILE" ]; then
+                echo "Error: --profile is AWS-only and cannot be used with --cloud gcp" >&2
+                exit 1
+            fi
+            if [ "$REGION_EXPLICIT" = true ]; then
+                echo "Error: --region is AWS-only and cannot be used with --cloud gcp" >&2
+                exit 1
+            fi
+            ;;
+        *)
+            echo "Error: --cloud must be 'aws' or 'gcp' (got '$CLOUD')" >&2
+            exit 1
+            ;;
+    esac
+
     if [ "$COMMAND" = "init" ]; then
         if [ -z "$OPENBAO_URL" ]; then
             echo "OpenBao URL is required"; usage; exit 1
@@ -104,7 +143,11 @@ parse_args() {
 }
 
 check_prerequisites() {
-    for bin in bao jq aws; do
+    local cloud_bin="aws"
+    if [ "$CLOUD" = "gcp" ]; then
+        cloud_bin="gcloud"
+    fi
+    for bin in bao jq "$cloud_bin"; do
         if ! command -v "$bin" &> /dev/null; then
             echo "Error: $bin is not installed"
             exit 1
@@ -174,29 +217,66 @@ check_openbao_status() {
     return 1
 }
 
-create_or_update_secret() {
-    local aws_cmd=$1
-    local secret_name=$2
-    local secret_value=$3
-
-    if $aws_cmd secretsmanager describe-secret --secret-id "$secret_name" >/dev/null 2>&1; then
-        log_message "INFO" "Secret $secret_name exists, updating it..."
-        if ! $aws_cmd secretsmanager update-secret --secret-id "$secret_name" --secret-string "$secret_value" >/dev/null 2>&1; then
-            log_message "ERROR" "Failed to update secret $secret_name"
-            return 1
+# Write a secret value, creating the secret if it does not exist. Dispatches
+# on $CLOUD so init_openbao() and write_ca() don't need to know which backend
+# they're talking to.
+# Usage: secret_write <name> <value>
+secret_write() {
+    local secret_name=$1
+    local secret_value=$2
+
+    if [ "$CLOUD" = "gcp" ]; then
+        if gcloud secrets describe "$secret_name" --project "$PROJECT" >/dev/null 2>&1; then
+            log_message "INFO" "Secret $secret_name exists, updating it..."
+            if ! printf '%s' "$secret_value" | gcloud secrets versions add "$secret_name" \
+                --project "$PROJECT" --data-file=- >/dev/null 2>&1; then
+                log_message "ERROR" "Failed to update secret $secret_name"
+                return 1
+            fi
+        else
+            log_message "INFO" "Secret $secret_name does not exist, creating it..."
+            if ! printf '%s' "$secret_value" | gcloud secrets create "$secret_name" \
+                --project "$PROJECT" --replication-policy=automatic --data-file=- >/dev/null 2>&1; then
+                log_message "ERROR" "Failed to create secret $secret_name"
+                return 1
+            fi
         fi
+        log_message "INFO" "Successfully updated GCP Secret Manager entry for $secret_name"
     else
-        log_message "INFO" "Secret $secret_name does not exist, creating it..."
-        if ! $aws_cmd secretsmanager create-secret --name "$secret_name" --secret-string "$secret_value" >/dev/null 2>&1; then
-            log_message "ERROR" "Failed to create secret $secret_name"
-            return 1
+        local aws_cmd; aws_cmd=$(get_aws_cmd)
+        if $aws_cmd secretsmanager describe-secret --secret-id "$secret_name" >/dev/null 2>&1; then
+            log_message "INFO" "Secret $secret_name exists, updating it..."
+            if ! $aws_cmd secretsmanager update-secret --secret-id "$secret_name" --secret-string "$secret_value" >/dev/null 2>&1; then
+                log_message "ERROR" "Failed to update secret $secret_name"
+                return 1
+            fi
+        else
+            log_message "INFO" "Secret $secret_name does not exist, creating it..."
+            if ! $aws_cmd secretsmanager create-secret --name "$secret_name" --secret-string "$secret_value" >/dev/null 2>&1; then
+                log_message "ERROR" "Failed to create secret $secret_name"
+                return 1
+            fi
         fi
+        log_message "INFO" "Successfully updated AWS Secrets Manager entry for $secret_name"
     fi
 
-    log_message "INFO" "Successfully updated AWS Secrets Manager entry for $secret_name"
     return 0
 }
 
+# Read the current value of a secret to stdout.
+# Usage: secret_read <name>
+secret_read() {
+    local secret_name=$1
+
+    if [ "$CLOUD" = "gcp" ]; then
+        gcloud secrets versions access latest --secret "$secret_name" --project "$PROJECT"
+    else
+        local aws_cmd; aws_cmd=$(get_aws_cmd)
+        $aws_cmd secretsmanager get-secret-value --secret-id "$secret_name" \
+            --query SecretString --output text
+    fi
+}
+
 # Initialize OpenBao
 #
 # The recovery keys are persisted, in their own secret. Previously only the
@@ -243,22 +323,20 @@ init_openbao() {
         exit 1
     fi
 
-    AWS_CMD=$(get_aws_cmd)
-
-    log_message "INFO" "Storing root token in AWS Secrets Manager..."
+    log_message "INFO" "Storing root token..."
     root_token_value=$(jq -n --arg token "$root_token" '{"token": $token}')
-    if ! create_or_update_secret "$AWS_CMD" "$ROOT_TOKEN_SECRET_NAME" "$root_token_value"; then
-        log_message "ERROR" "Failed to store root token in AWS Secrets Manager"
+    if ! secret_write "$ROOT_TOKEN_SECRET_NAME" "$root_token_value"; then
+        log_message "ERROR" "Failed to store root token"
         exit 1
     fi
 
-    log_message "INFO" "Storing recovery keys in AWS Secrets Manager..."
+    log_message "INFO" "Storing recovery keys..."
     recovery_value=$(jq -n \
         --argjson keys "$recovery_keys" \
         --argjson threshold "$RECOVERY_THRESHOLD" \
         '{"recovery_keys": $keys, "recovery_key": $keys[0], "threshold": $threshold}')
-    if ! create_or_update_secret "$AWS_CMD" "$RECOVERY_KEYS_SECRET_NAME" "$recovery_value"; then
-        log_message "ERROR" "Failed to store recovery keys in AWS Secrets Manager"
+    if ! secret_write "$RECOVERY_KEYS_SECRET_NAME" "$recovery_value"; then
+        log_message "ERROR" "Failed to store recovery keys"
         exit 1
     fi
 
@@ -274,12 +352,36 @@ init_openbao() {
 # Write the CA chain to disk so the Vault provider can verify the server
 # certificate (var.openbao_ca_cert_file in the management stack). A provider
 # block cannot depend on a resource, so this cannot be a local_file.
+#
+# The secret's SHAPE differs by cloud, and that is by design, not an
+# inconsistency to paper over:
+#   - AWS: the root-CA secret (certificates/priv.aws.ogenki.io/root-ca) is
+#     hand-loaded per the manual ceremony in pki-and-secrets.md as JSON with
+#     `.ca` (and `.bundle`) fields.
+#   - GCP: openbao-priv-gcp-ca-chain is raw PEM (`gcloud secrets create
+#     ... --data-file=ca-chain.pem`, plan Task 3 Step 6) -- PEM is the natural
+#     shape for a CA bundle, and the file is consumed directly as
+#     VAULT_CACERT. No root-CA secret exists on GCP at all; only the chain.
+# So the read has to branch on $CLOUD rather than assume one shape for both.
 write_ca() {
-    AWS_CMD=$(get_aws_cmd)
+    local raw
+    if ! raw=$(secret_read "$ROOT_CA_SECRET_NAME"); then
+        log_message "ERROR" "Failed to retrieve the CA chain from $ROOT_CA_SECRET_NAME"
+        exit 1
+    fi
 
-    ca_chain=$($AWS_CMD secretsmanager get-secret-value \
-        --secret-id "$ROOT_CA_SECRET_NAME" \
-        --query "SecretString" --output text | jq -r '.ca // empty')
+    if [ "$CLOUD" = "gcp" ]; then
+        ca_chain="$raw"
+    else
+        # Guarded explicitly rather than left to `pipefail`: piping `$raw`
+        # through `jq` and letting a parse failure propagate would still exit
+        # non-zero, but via jq's own stderr rather than this script's error
+        # message, and set -e would kill the script before the friendly
+        # message below ever printed.
+        if ! ca_chain=$(printf '%s' "$raw" | jq -r '.ca // empty' 2>/dev/null); then
+            ca_chain=""
+        fi
+    fi
 
     if [ -z "$ca_chain" ]; then
         log_message "ERROR" "Failed to retrieve the CA chain from $ROOT_CA_SECRET_NAME"