Tres agujeros que encontro una review adversarial de Codex sobre el trabajo
de ayer. Los tres verificados contra el fichero antes de tocar nada.
1. El webhook publico fallaba en ABIERTO. Con `optional: true` y un
`if (secreto && ...)`, la ausencia del secreto equivalia a autorizacion:
cualquier POST con heartbeat.status=0 y un monitor.name del mapa reiniciaba
n8n, Gitea, ArgoCD, Vaultwarden o los blogs. El argumento para dejarlo asi
era "que un despiste no te deje sin avisos", y era falso: el aviso de caida
lo manda Kuma por su notificacion 1, directa, no por este webhook.
Ahora el secreto es obligatorio (sin `optional`) y la puerta rechaza si
falta. Secreto ausente da error ruidoso; cabecera que no casa, vacio.
2. El ClusterRole permitia patch sobre CUALQUIER deployment de 10 namespaces,
y la SA va montada en el pod entero de n8n: cualquier workflow con un nodo
Code heredaba eso. Ahora son Roles por namespace con resourceNames sobre
los 12 workloads exactos del SERVICE_MAP.
3. El flujo daba exito aunque el PATCH fallara. `restartOk` se calculaba y se
tiraba: `K8s API Check Status` construia un objeto nuevo sin el, y el IF
final solo miraba `statusOk`. Un 403 sobre un servicio ya sano mandaba
"reiniciado correctamente". Ahora hay rama de fallo tras el PATCH y el
exito exige observedGeneration >= la generation que devolvio el PATCH.
Se compara con >= porque selfHeal de ArgoCD revierte la anotacion y vuelve
a subir la generation; con == daria un fallo falso.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ghost EN y ES son lo unico del mapa que da la cara al publico y lo que peor se
lleva con dos semanas sin nadie mirando. Entran en el SERVICE_MAP con la clave
igual al nombre exacto del monitor de Kuma.
El monitor "www.zonadeexclusion.com (301->apex)" se queda fuera a proposito:
que ese 301 falle es cosa de Traefik o del DNS, no de Ghost.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El workflow "Uptime Kuma -> K8s Auto-Restart" lleva desde siempre sin poder
reiniciar nada: hacia el PATCH con el token de la ServiceAccount "default" del
namespace, que no tiene ni un permiso, y el API contestaba 403. Se iba entonces
por la rama de "reinicio fallido" y mandaba el aviso por Telegram -- que se
enviaba bien, y por eso los 23 "exitos" de workflow_statistics. La integracion
parecia viva y no lo estaba.
SA propia (n8n-restarter) en vez de la default, y un RoleBinding por namespace
en lugar de un ClusterRoleBinding: el webhook que dispara esto es publico y sin
autenticar, asi que el alcance se limita al SERVICE_MAP del workflow.
El ClusterRole incluye get ademas de patch porque el workflow relee el objeto a
los 60 s para comprobar readyReplicas (sin get: "Cannot read properties of
undefined"), y statefulsets ademas de deployments porque Gitea es lo primero.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
chemavxandClaude Opus 5