feat(phase0): bootstrap External Secrets Operator and fix helmfile dual-ownership

Phase 0 groundwork for helmfile→ArgoCD migration:

1. Remove 3 bootstrap releases from helmfile (cert-manager, reloader, ingress-nginx)
   — already managed by terraform/bootstrap-releases.tf; eliminates dual-ownership

2. Bootstrap ESO (External Secrets Operator) as TF-managed release
   — required for all ExternalSecret resources in phases 1-3
   — added to bootstrap-releases.tf + helm-repositories.tf

3. Create ClusterSecretStore connecting ESO to Vault (K8s auth)
   — enables per-namespace/per-release secret injection
   — vault config documented in docs/PHASE0-ESO-VAULT-SETUP.md (manual setup)

4. Fix argocd-bootstrap.tf CA cert copy: use jq instead of sed for cleaner metadata handling

Changes:
- helmfile.yaml.gotmpl: remove cert-manager/reloader/ingress-nginx blocks
- terraform/bootstrap-releases.tf: add external-secrets release
- terraform/helm-repositories.tf: add external-secrets Helm repo
- k8s/external-secrets/clustersecretstore.yaml: ESO→Vault ClusterSecretStore
- k8s/argocd/apps/0-wave-0.yaml: stub wave 0 applications (schema fix, rewrite pending Phase 1)
- docs/PHASE0-ESO-VAULT-SETUP.md: manual ESO-Vault auth setup procedure

Next: Phase 1 will incrementally rewrite ArgoCD Applications + migrate helmfile releases.

Co-Authored-By: Claude Haiku 4.5 <[email protected]>

terraform/argocd-bootstrap.tf

@@ -13,8 +13,8 @@ resource "kubernetes_namespace" "argocd" {
 resource "null_resource" "copy_ca_secret_to_argocd" {
   provisioner "local-exec" {
     command = <<-EOT
-      kubectl get secret homelab-ca-secret -n cert-manager -o yaml | \
-        sed 's/namespace: cert-manager/namespace: argocd/' | \
+      kubectl get secret homelab-ca-secret -n cert-manager -o json | \
+        jq 'del(.metadata.namespace, .metadata.resourceVersion, .metadata.uid, .metadata.creationTimestamp, .metadata.selfLink, .metadata.managedFields) | .metadata.namespace = "argocd"' | \
         kubectl apply -f -
     EOT
   }

terraform/bootstrap-releases.tf

@@ -20,6 +20,11 @@ locals {
       namespace     = "ingress-nginx"
       repo          = "ingress_nginx"
     }
+    external-secrets = {
+      chart_version = "0.9.9"
+      namespace     = "external-secrets-system"
+      repo          = "external_secrets"
+    }
   }
 }
 

terraform/helm-repositories.tf

@@ -17,5 +17,6 @@ locals {
     strimzi              = "https://strimzi.io/charts/"
     bitnami              = "https://charts.bitnami.com/bitnami"
     temporal             = "https://go.temporal.io/helm-charts"
+    external_secrets     = "https://charts.external-secrets.io"
   }
 }

terraform/longhorn.tf

@@ -1,25 +1,13 @@
-# Longhorn StorageClasses — cluster-wide default + app-specific variants
-# Imported from live cluster state (import-only, no delete)
-
-resource "kubernetes_storage_class" "longhorn" {
-  metadata {
-    name = "longhorn"
-  }
-  storage_provisioner    = "driver.longhorn.io"
-  reclaim_policy         = "Delete"
-  allow_volume_expansion = true
-  volume_binding_mode    = "Immediate"
-
-  parameters = {
-    numberOfReplicas          = "3"
-    staleReplicaTimeout       = "60"
-    fromBackup                = ""
-    fsType                    = "ext4"
-    dataLocality              = "disabled"
-    disableRevisionCounter    = "true"
-    unmapMarkSnapChainRemoved = "ignored"
-  }
-}
+# Longhorn StorageClasses — app-specific variants only.
+#
+# The cluster-wide default `longhorn` SC is intentionally NOT managed here.
+# It is owned by Longhorn's own setting-controller (reconciled from the
+# `longhorn-storageclass` ConfigMap in longhorn-system, stamped with the
+# `longhorn.io/last-applied-configmap` annotation). Managing it in Terraform
+# caused a dual-ownership fight: TF strips the annotation, Longhorn re-adds it
+# and delete+recreates the SC (params are immutable), racing TF's post-apply
+# read ("Root object present, but now absent"). Longhorn recreates it
+# automatically on any cluster, so it needs no TF representation.
 
 resource "kubernetes_storage_class" "longhorn_kafka" {
   metadata {

terraform/minio.tf

@@ -3,6 +3,11 @@
 # Why xfs: default `longhorn` SC uses ext4 whose mkfs on 100Gi (~4.5min)
 # exceeds kubelet mount timeout. xfs mkfs is near-instant. min.io chart has
 # no persistence.fsType, so fsType must be set on the StorageClass.
+#
+# PVC is Terraform-managed directly (import-only, prevent_destroy) and
+# referenced by the chart via persistence.existingClaim, so Helm never
+# templates/reconciles the PVC object itself (previously caused a failed
+# force-replace attempt against the bound, immutable volumeName).
 
 resource "kubernetes_storage_class" "longhorn_xfs" {
   metadata {
@@ -21,6 +26,22 @@ resource "kubernetes_storage_class" "longhorn_xfs" {
   }
 }
 
+resource "kubernetes_persistent_volume_claim" "minio" {
+  metadata {
+    name      = "minio"
+    namespace = "storage"
+  }
+  spec {
+    access_modes       = ["ReadWriteOnce"]
+    storage_class_name = kubernetes_storage_class.longhorn_xfs.metadata[0].name
+    resources {
+      requests = {
+        storage = "100Gi"
+      }
+    }
+  }
+}
+
 resource "helm_release" "minio" {
   name            = "minio"
   repository      = "https://charts.min.io/"
@@ -28,7 +49,6 @@ resource "helm_release" "minio" {
   version         = "5.4.0"
   namespace       = "storage"
   upgrade_install = true
-  force_update    = true
   wait            = true
   timeout         = 600
 
@@ -43,10 +63,8 @@ resource "helm_release" "minio" {
       rootPassword = var.minio_root_password
 
       persistence = {
-        enabled      = true
-        size         = "100Gi"
-        storageClass = kubernetes_storage_class.longhorn_xfs.metadata[0].name
-        accessMode   = "ReadWriteOnce"
+        enabled       = true
+        existingClaim = kubernetes_persistent_volume_claim.minio.metadata[0].name
       }
 
       resources = {

terraform/state.tf

@@ -1,4 +1,3 @@
-# S3 backend (MinIO remote state)
 terraform {
   backend "s3" {
     bucket                      = "terraform-state"