From 440eb5b6a16cae70d9120b75061b30b7a825c231 Mon Sep 17 00:00:00 2001 From: chemavx Date: Thu, 30 Jul 2026 19:58:29 +0000 Subject: [PATCH] n8n: dar permisos de reinicio al auto-restart de Uptime Kuma 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 --- n8n/deployment-n8n.yaml | 4 ++ n8n/rbac-restarter.yaml | 145 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 149 insertions(+) create mode 100644 n8n/rbac-restarter.yaml diff --git a/n8n/deployment-n8n.yaml b/n8n/deployment-n8n.yaml index 9c03e06..07aee9e 100644 --- a/n8n/deployment-n8n.yaml +++ b/n8n/deployment-n8n.yaml @@ -23,6 +23,10 @@ spec: labels: app: n8n spec: + # El workflow del auto-reinicio lee el token proyectado de ESTA SA para + # hablar con el API de K8s (ver rbac-restarter.yaml). Hasta el 2026-07-30 + # heredaba la "default", que no tiene ningún permiso: 403 en cada intento. + serviceAccountName: n8n-restarter securityContext: fsGroup: 1000 runAsUser: 1000 diff --git a/n8n/rbac-restarter.yaml b/n8n/rbac-restarter.yaml new file mode 100644 index 0000000..bf64982 --- /dev/null +++ b/n8n/rbac-restarter.yaml @@ -0,0 +1,145 @@ +# Permisos para el workflow "Uptime Kuma -> K8s Auto-Restart" (2026-07-30). +# +# El nodo Code lee el token proyectado de la ServiceAccount y hace un PATCH +# contra kubernetes.default.svc. Nunca habia existido ningun Role ni RoleBinding +# para n8n: el API devolvia 403 y el workflow se iba por la rama de "reinicio +# fallido". Los 23 "exitos" de workflow_statistics eran eso -- el aviso de fallo +# enviandose bien. La integracion jamas reinicio nada. +# +# SA propia y no la "default" del namespace: cualquier pod que se despliegue en +# n8n sin pedir SA hereda la default, y estos permisos cruzan namespaces. +apiVersion: v1 +kind: ServiceAccount +metadata: + name: n8n-restarter + namespace: n8n +--- +# get ademas de patch: tras el PATCH el workflow espera 60 s y RELEE el +# deployment para comprobar readyReplicas -- sin get, ese chequeo posterior +# devolvia "Cannot read properties of undefined (reading 'replicas')". +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: n8n-restarter +rules: + - apiGroups: ["apps"] + # statefulsets porque Gitea lo es (no un Deployment) y esta en el mapa. + resources: ["deployments", "statefulsets"] + verbs: ["get", "patch"] +--- +# Un RoleBinding por namespace y no un ClusterRoleBinding: el webhook que +# dispara esto es PUBLICO y sin autenticar, asi que el alcance de lo que +# puede reiniciar un desconocido debe ser exactamente el SERVICE_MAP. +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: n8n +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: monitoring +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: homarr +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: gitea +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: authentik +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: vaultwarden +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: ollama +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n +--- +# argocd el ultimo a proposito: reiniciar argocd-server o argocd-repo-server +# es lo mas agresivo del mapa (deja el cluster sin reconciliar un rato). +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: n8n-restarter + namespace: argocd +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: n8n-restarter +subjects: + - kind: ServiceAccount + name: n8n-restarter + namespace: n8n