Skip to content

SVC-DEV-WILDCARD: Wildcard TLS *.d.wetopi.com

¿Qué es?

El mecanismo que expone los wepods de desarrollo del cluster d en https://<wepod>.d.wetopi.com con UN solo certificado. ADR-0020 (accepted de facto por GO + ejecución 2026-09-10): wildcard LE PROD en el Gateway + DNS wildcard + onboarding por HTTPRoute.

¿Cómo se opera?

Onboarding de un wepod nuevo (el flujo rápido que motivó el diseño):

  1. Namespace (o reutiliza uno) + Service del wepod.
  2. HTTPRoute con hostname EXACTO <wepod>.d.wetopi.com, parentRef kube-system/wetopi-edge, sectionName https, port 8443 implícito.
  3. Nada más. El cert wildcard lo cubre; el DNS *.d ya resuelve.

Manifest mínimo:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: <wepod>
  namespace: <ns-del-wepod>
spec:
  parentRefs:
  - name: wetopi-edge
    namespace: kube-system
    sectionName: https
  hostnames: ["<wepod>.d.wetopi.com"]
  rules:
  - backendRefs:
    - name: <svc-del-wepod>
      port: 80

Salud: kubectl -n kube-system get certificate dev-wildcard-tls (Ready); SNI a cualquier edge con un hostname *.d.wetopi.com debe servir CN=*.d.wetopi.com (LE). Renovación: cert-manager, automática (~60d antes de los 90 días).

Componentes (todos live 2026-09-10):

Componente Dónde Estado
Certificate dev-wildcard-tls (LE prod) kube-system Ready; Secret kubernetes.io/tls
Certificate dev-wildcard-tls-staging (gate) kube-system Ready (gemelo de test, no servido)
certRefs en Gateway wetopi-edge (13) kube-system Programmed, ResolvedRefs=True
DNS d + *.d A .193/.194 zona wetopi.com (tofu) Live, round-robin TTL 300
Soporte multi-zona tofu infrastructure PR #51 zone_id por-record + coalesce

¿Cómo se rompe y se arregla?

  • SNI *.d.wetopi.com sirve default cert → el certRef dev-wildcard-tls desapareció del Gateway (lección 2026-09-10: un apply con yaml desactualizado borra certRefs silenciosamente — ver incidente cerebro abajo). Fix: kubectl patch json añadiendo el certRef, o re-apply del fichero de main actualizado.
  • Cert staging no Ready en una zona nueva → el token Cloudflare no cubre esa zona (zone-discovery del solver falla). Fix: ampliar scope del token (Zone-DNS-Edit + Zone-Read).
  • tofu plan muestra adds de records existentes → state local desincronizado (lección 2026-09-10: el state de ops01 no tenía los cloudflare resources de las cards F3/F5). Operar con plan -target a los recursos nuevos; nunca re-crear duplicados.
  • Renovación: automática por cert-manager; el Secret se reescribe y el listener lo recoge sin apply.

Estado honesto (live, 2026-09-10)

DEPLOYED. Cadena completa ejecutada: staging gate OK → prod Ready → tofu DNS apply (4 records, targeted plan tras detectar state desincronizado) → Gateway certRef apply. Verificación pública: SNI demo-joan.d.wetopi.com / test-wepod.d.wetopi.com → CN=*.d.wetopi.com (LE YR2) verify=0 en ambos edges; co-tenants sin regresión.

Incidente colateral reparado (cerebro): el SNI cerebro.wetopi.net servía default cert — NO causado por el wildcard: la card dashboards (~17:00 UTC del 2026-09-10) había sustituido cerebro-tls por dashboards-tls en el Gateway. Reparado en vivo (patch json re-añadiendo cerebro-tls) y Git alineado en platform-edge PR #9 (merged: 13 certRefs). Lección registrada: aplicar el Gateway con yaml desactualizado = borrado silencioso de certRefs; SIEMPRE comparar kubectl get gateway -o yaml con el fichero antes de aplicar, y re-probar todos los co-tenants tras cada gateway-apply.

Notas de operación

  • Añadir un wepod NO toca: cert-manager, DNS, Gateway. Solo HTTPRoute+Service.
  • ADR-0006 sigue: wepods dev son operator-only; el L4/v2 edge sigue siendo precondición para clientes externos.
  • Futura mejora opcional (ADR-0020 D4): catch-all wildcard-hostname en HTTPRoute (Traefik no lo documenta; validar con wepod real antes de depender).
  • PRs de nacimiento: infrastructure #50 (certs), #51 (DNS), platform-edge #6 (certRef), #9 (restauración cerebro).