Thore CimbalandClaude Opus 4.8
463fb570d5
Inventoried the 24 git.lab PATs by metadata only — last_used_at separates 'needed' from 'lying around': four are in active use, five are active but never used at all (one with manage_runner and k8s scope), and several names exist twice because a replacement was created without revoking the old one. All six push mirrors are healthy, but GitLab masks both parts of the mirror URL, so the credential remains unidentifiable — and it is a Gitea token, which the PAT list cannot answer for. Hence the ordering: set a dedicated mirror credential first, revoke second. The revocations themselves are sorb's; from here a never-used token is indistinguishable from a staged one. W5 resolved: the secrets rule now has a bootstrap exception, since on a headless host it was only satisfiable by violating it. W4 splits — point 5 is #0015 (plus the WG key, which no token inventory covers), point 4 is demonstrably undone. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6.0 KiB
type, id, status, created, milestone, priority, due, host, area, gitlab_iid, related
| type | id | status | created | milestone | priority | due | host | area | gitlab_iid | related | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| issue | 0015 | in-progress | 2026-08-01 | M2 | medium | 2026-08-31 | cfgmon | security | 15 |
|
CFGMON-15: Token-Hygiene — Einmal-Tokens der LABNET-02-Nacht widerrufen
Import aus management#15 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
Gemeldet von der CFGMON-Session am Ende der LABNET-02-Nacht.
Während der Arbeit entstanden vier Einmal-Tokens für Issue-Kommentare/Pushes, dazu existiert noch das erste git.lab-Token aus dem Erstzugang. Alle sind nach Abschluss von LABNET-02 funktionslos.
Zu tun: Bestand aufnehmen (Gitea-Access-Tokens + GitLab-PATs), nicht mehr benötigte widerrufen, verbleibende mit Ablaufdatum und sprechendem Namen versehen.
⚠️ Randbedingung aus der Mirror-Diskussion: Welcher Token in den Push-Mirrors der fünf gespiegelten Repos hinterlegt ist, ist derzeit nicht rekonstruierbar (die API maskiert ihn, in keiner Session dokumentiert). Ein Widerruf kann deshalb still einen Mirror brechen. Vor der Rotation: entweder die Mirror-Credentials bewusst neu setzen, oder nach dem Widerruf jeden Mirror-Status einmal prüfen (GET /projects/<id>/remote_mirrors → last_error).
Bestandsaufnahme 2026-08-15
git.lab-PATs: 24 Stück, davon 13 aktiv
Abgefragt über GET /personal_access_tokens — nur Metadaten, keine Werte (die gibt die API
ohnehin nur bei der Erzeugung heraus). last_used_at ist dabei der eigentliche Hebel: er
trennt „wird gebraucht" von „liegt herum".
Aktiv und nachweislich in Gebrauch — NICHT anfassen:
| id | Name | Scopes | zuletzt genutzt |
|---|---|---|---|
| 6 | gitlab claude token | api | 2026-08-15 (heute — Session-Zugang) |
| 24 | wiki-canonize | write_repository | 2026-08-15 (CI-Kanonisierung) |
| 8 | Gitea-push-token | api, write_registry | 2026-08-14 |
| 19 | management#31 | read_api | 2026-08-14 |
Aktiv, aber NIE benutzt — die eigentliche Hygiene-Baustelle:
| id | Name | Scopes | angelegt |
|---|---|---|---|
| 18 | oskar light | api, read_api, manage_runner, k8s | 2026-08-04 |
| 9 | registry-cleanup | api, read/write_registry | 2026-08-03 |
| 11 | herold-hive | read/write_repository | 2026-08-04 |
| 15 | oskar read | read_service_ping, read_user, … | 2026-08-04 |
| 23 | wiki-canonize | write_repository | 2026-08-13 — Dublette zu id=24 |
Aktiv, einmal benutzt, seither still: id=4 tabby (27.07.), id=10 SORB API (04.08.),
id=13 herold (04.08.), id=17 oskar analyse (09.08.).
Bereits inaktiv (nichts zu tun): ids 1, 2, 3, 5, 7, 12, 14, 16, 20, 21, 22.
Auffällig ist ein Muster: mehrere Namen existieren doppelt, einmal aktiv und einmal
inaktiv (herold, oskar read, oskar analyse, wiki-canonize) — offenbar wurde jeweils
neu erzeugt, ohne das alte zu widerrufen. Genau daraus entsteht der Wildwuchs, den dieses
Issue adressiert.
Push-Mirrors: alle gesund, Konto aber weiterhin unbekannt
Sechs Mirrors, alle finished, kein last_error (Stand 2026-08-15): ThreadNet-Web,
gitops, thread-net-git, threadnet-call, threadnet-operating, management.
⚠️ Die Warnung des Issues bestätigt sich: GitLab maskiert in remote_mirrors beide Teile
der URL (https://*****:*****@rohana…). Es ist also weder Konto noch Token rekonstruierbar.
Und: die Mirrors authentifizieren sich gegen Gitea, das gesuchte Credential ist damit ein
Gitea-Token, kein git.lab-PAT — die PAT-Liste oben kann die Frage gar nicht beantworten.
(Nebenbefund: gameserver hat wirklich keinen Mirror → bestätigt #0032. notfallhandbuch
bewusst nicht → ADR-0016. threadnet-wiki braucht keinen, es läuft in Gegenrichtung.)
Empfehlung — Reihenfolge zählt
- Mirror-Credential bewusst neu setzen, bevor irgendetwas widerrufen wird. Ein
dedizierter Gitea-Token (Name z.B.
gitlab-mirror, Scopewrite:repository, mit Ablaufdatum), auf allen sechs Mirrors hinterlegt. Danach ist bekannt und dokumentiert, woran sie hängen — die Unklarheit verschwindet, statt umschifft zu werden. - Erst dann Gitea-Alttokens widerrufen, anschließend alle sechs Mirrors einmal prüfen
(
GET /projects/<id>/remote_mirrors→last_error). - git.lab-PATs aufräumen: die fünf nie benutzten zuerst (id 18, 9, 11, 15, 23) — id=18
ist wegen
manage_runner+k8sder unangenehmste Fund. Danach die vier Einmal-Nutzer (4, 10, 13, 17), sofern die zugehörigen Werkzeuge nicht mehr laufen. - Verbleibende mit sprechendem Namen und Ablaufdatum versehen — mehrere laufen Ende August/Anfang September ohnehin aus, das ist der natürliche Zeitpunkt.
Die Widerrufe selbst gehören sorb (Credentials legt/entfernt der Mensch); ich habe
bewusst nichts widerrufen — bei Namen wie herold, oskar, tabby ist von hier nicht
erkennbar, ob dahinter ein laufendes Werkzeug steht. last_used_at = None heißt „nie
benutzt", nicht „nicht gebraucht": ein hinterlegter, aber noch nicht ausgelöster Token sieht
genauso aus.
Bezug zu #0027 (W4/W5)
- W5 aufgelöst: Die Secrets-Regel in
AGENTS.mdhat jetzt eine Bootstrap-Ausnahme — auf einem Host, wo sorb die Datei nicht selbst anlegen kann, darf eine Session das Credential schreiben, aber es gilt als exponiert (Rotationspflicht), wird mit Pfad+Zweck festgehalten und bekommt ein fälliges Issue. Damit ist die Regel erfüllbar, ohne sie zu brechen. - W4 Punkt 5 (Rotation der in der LABNET-02-Nacht exponierten Werte) ist inhaltlich dieses Issue — der WG-Private-Key gehört ausdrücklich dazu und ist oben nicht abgedeckt (er ist kein API-Token): separat rotieren.
- W4 Punkt 4 (Repo-Zuhause für
lab.conf, systemd-Drop-in, Root-CA) ist nachweislich offen:gitops:host-config/existiert als Muster, enthält aber nurmaintenance-notify. Die Schließung von #16 war für diesen Punkt also verfrüht.