Auf dieser Seite
4 Min. Lesezeit

Tag 15 - OpenCloud-Registrierung: abgelaufenes Graph-Token und Auto-Erneuerung

Ein abgelaufenes Graph-Token blockierte die E-Mail-Registrierung bei KM0 Cloud; wir dokumentieren die Ursache, sichere register-api-Token-Rotation und Fehler bei der Automatisierung.

Einleitung

Am Tag 15 kehren wir zur operativen Infrastruktur im Schwesterprojekt km0-opencloud zurück. Am 4. Juli 2026 versuchte ein Nutzer, sich mit E-Mail und Passwort bei KM0 Cloud zu registrieren, und sah eine generische Fehlermeldung. Google OAuth funktionierte weiter. Die Ursache: das register-api Graph-Token war abgelaufen.

In Issue #17 implementierten wir manuelle Rotation, sichere Auto-Erneuerung und beheben zwei Defekte, die der Tester bei der Skript-Validierung fand. Dieser Artikel erklärt, was passierte, warum es wichtig ist und was jetzt automatisiert ist.

Vorfall

Was der Nutzer sah

Das Formular zeigte die generische Meldung «Konto konnte nicht erstellt werden. Bitte später erneut versuchen.» ohne Hinweis, dass der Dienst vorübergehend ausfiel. Derselbe Nutzer meldete sich später problemlos mit Google OAuth an.

  • Ursache: abgelaufenes oder ungültiges GRAPH_SERVICE_APP_TOKEN für register-api; Graph lehnte die Credentials ab.
  • Beleg: GET /health lieferte graph_auth_ok: false; POST /api/register antwortete HTTP 503.
  • OAuth intakt: Google-Login nutzt Dex + OIDC, nicht register-api; ein Weg funktionierte, der andere nicht.
  • Vorheriger Kontext: Issue #16 hatte Formularfehler bereits verbessert; an diesem Tag adressieren wir die operative Ursache des 503.

Warum

Warum register-api ein Token braucht

Die E-Mail/Passwort-Registrierung bei KM0 Cloud läuft über einen Sidecar, register-api, der Nutzer via OpenCloud Graph anlegt (POST /graph/v1.0/users). In Produktion akzeptiert Graph kein Passwort-Basic-Auth; register-api muss sich mit einem dedizierten Graph App Token authentifizieren.

Operatives Geheimnis

Dieses Token ist ein Secret mit Ablaufdatum. Läuft es ab und niemand erneuert es, fällt die manuelle Registrierung still aus, während OAuth weiterläuft. Behandeln Sie es als Infrastruktur-Credential, nicht als «einmal setzen und vergessen».

Implementierung

Rotation und Auto-Erneuerung (Issue #17)

  • Policy: Token nur für register-api, 3 Monate Laufzeit, Auto-Erneuerung wenn weniger als 14 Tage verbleiben.
  • setup-register-api-graph-token.sh: erstellt Token mit --expires-in 90d, schreibt GRAPH_SERVICE_APP_TOKEN und GRAPH_SERVICE_APP_TOKEN_EXPIRES_AT nach register-api/.env.
  • renew-register-api-graph-token.sh: prüft Health und Ablauf; erneuert bei graph_auth_ok: false oder knappem Puffer; startet nur register-api neu; verifiziert /health.
  • Cron: wöchentliche Vorlage (Montag 03:00 UTC) in register-api-token-renewal.cron.
  • Sicherheit: der Prozess berührt nie Nutzer, Volumes, Dex/OIDC, Datenbanken oder restliches OpenCloud-.env.

Gefundene Fehler

Was bei der Automatisierung scheiterte

Die erste Version des Erneuerungs-Skripts bestand grundlegende manuelle Tests, aber der Tester fand zwei Defekte bei echten Cron- und Erzwingungs-Szenarien.

  • Falscher Graph-Nutzer: das Erneuerungs-Skript propagierte GRAPH_SERVICE_USER nicht aus register-api/.env. Setup erzeugte das Token für den Standardnutzer (admin) statt den konfigurierten Operator. Fix: GRAPH_SERVICE_USER aus .env lesen und mit --user an Setup übergeben.
  • Race nach Neustart: verify-register-api.sh lief unmittelbar nach docker compose up und scheiterte, weil register-api noch nicht vollständig startete. Fix: aktives Warten bis 30 s (REGISTER_API_HEALTH_WAIT_SEC) mit Prüfung auf graph_auth_ok: true vor Verify.

Nach diesen Änderungen endeten Skip-, Erzwingungs- und 7-Tage-Schwellen-Szenarien mit Exit 0 und graph_auth_ok: true.

Grenzen

Was Erneuerung nie tun darf

Explizite Grenzen im km0-opencloud-Runbook verhindern, dass ein automatisiertes Skript Produktion beschädigt.

  • Kein docker compose down -v, docker volume rm oder OpenCloud-Nutzer-Reset.
  • Keine Änderung an Dex, OIDC, Storage, Datenbanken oder bestehenden Gruppen.
  • Nur register-api-Token aktualisieren, diesen Container neu starten, Health prüfen.
  • Bei fehlgeschlagener Erneuerung bleiben Google OAuth und bestehende Nutzerdaten unberührt.

KM0

Warum wir das im Blog erzählen

KM0 verspricht nahe, betreibbare Dienste: Cloud, Mail und Web unter Ihrer Kontrolle. Ein abgelaufenes Token erinnert daran, dass Betrieb genauso wichtig ist wie Deployment.

  • Transparenz: scheitert E-Mail-Registrierung, gibt es typisierte Meldungen (Issue #16) und dokumentierte Rotationsverfahren.
  • Sichere Automatisierung: wöchentliche Erneuerung mit minimalem Scope, keine «Helden-Skripte», die den ganzen Stack neu starten.
  • Serie: Tag 14 behandelte KI und Bürokratie; hier ist die Bürokratie ein Token mit Ablaufdatum und ein Cron, der es erneuert, bevor Nutzer es merken.

Verifikation

Registrierung prüfen

  1. Health: Operatoren können ./scripts/verify-register-api.sh in km0-opencloud ausführen und graph_auth_ok: true bestätigen.
  2. Registrierung: E-Mail/Passwort-Registrierung testen oder mit Google anmelden, wenn Sie bereits ein Konto haben.
  3. Serie: Tag 14 (Harari und KI) und Tag 11 (KM0 Mail) lesen.
  4. Ideen: schreiben Sie uns über Ideenformular oder Kontakt, wenn Sie mehr Beiträge zum KM0-Cloud-Betrieb wünschen.

Serie

Frühere Tage

Am Tag 14 fassten wir Hararis Video über KI und Zivilisation zusammen; am Tag 13 Meet 6 zur Sichtbarkeit; am Tag 11 wurde KM0 Mail dokumentiert. Am Tag 16 kündigen wir das Treffen in El Masnou über KI, Bürokratie und Palantir an. Folgen Sie der Serie und testen Sie KM0 Cloud, wann Sie möchten.