Thore CimbalandClaude Opus 5
3f5da21f3e
sorb created the project access token with exactly what the job needs: Maintainer, because main is protected with push=Maintainers, and write_repository only, because the job pushes and never calls the API. Checked through the API without touching the value. Proven rather than assumed: a throwaway job pushed a ref with that token and removed it again, leaving main untouched and no branch behind. So the value reaches the job - protected variable on a protected branch - and it may write. The first real test is the rotation on 2026-09-01. Recorded as a future silent failure: the token expires 2027-08-19, and because the job runs green while idle, nobody would notice until the next real rotation after that date. Exactly the #0104 class, so it belongs in a calendar rather than in hope. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.9 KiB
type, id, status, created, milestone, priority, due, projekt, gitlab_iid, related
| type | id | status | created | milestone | priority | due | projekt | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|---|
| issue | 0084 | done | 2026-08-02 | M1 | medium | 2026-09-01 | gitops | 51 |
CI: CANONIZE_TOKEN für die automatische TURN-Rotation hinterlegen
Adoptiert aus gitops#51 (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
Der Job canonize_rotation in .gitlab-ci.yml übernimmt die monatliche TURN-Rotation automatisch (kein Handgriff mehr, kein Kalendereintrag). Der Schedule läuft, zwei Probeläufe sind durch — es fehlt nur noch das Push-Token.
Was zu tun ist (2 Minuten, braucht deine Rechte)
- Settings → Access Tokens in diesem Projekt: Token anlegen
- Name z. B.
canonize-rotation - Rolle Maintainer (nötig, weil
mainprotected ist) - Scope
write_repository— mehr nicht - Ablauf: setzen und im Kalender vormerken, sonst steht der Job irgendwann still
- Name z. B.
- Settings → CI/CD → Variables: Variable
CANONIZE_TOKENmit dem Wert, masked und protected
Danach nichts weiter — der nächste Lauf nimmt sie von selbst.
Warum das nötig ist
Der Rotations-CronJob läuft im Cluster und erreicht git.lab nicht; er pusht seinen Branch nach Gitea. Von dort muss die Rotation über git.lab zurück, sonst überschreibt sie der nächste Mirror-Push und Flux spielt still das alte Shared Secret wieder ein — ein Fehler, der kein Symptom erzeugt.
Stand
| Job + Doku | ✅ 02c60cb, CLAUDE.md in beiden Repos |
| Schedule (täglich 17:05) | ✅ angelegt |
| Probelauf | ✅ Pipeline 161 grün: „Keine offene Rotation" |
CANONIZE_TOKEN |
⬜ dieses Issue |
Bis dahin ist nichts kaputt: Ohne offene Rotation läuft der Job grün durch. Erst wenn am 01.09. wirklich rotiert wird und das Token fehlt, bricht er ab — laut und sichtbar, statt still das Falsche zu tun.
Nebenbei aufgefallen: Der Branch turn-secret-rotation-20260728-192656 liegt auf git.lab und Gitea, steckt aber längst in main — eine Karteileiche vom Juli. Kann weg, ist aber harmlos.
Erledigt 2026-08-19 — Token angelegt und nachweislich wirksam
sorb hat den Project Access Token angelegt; die Eigenschaften stimmen mit dem überein, was der Job braucht (per API geprüft, ohne den Wert anzufassen):
| Name | canonize-rotation |
| Rolle | Maintainer — nötig, weil main mit push = Maintainers geschützt ist |
| Scopes | nur write_repository — der Job pusht, er ruft keine API auf |
| CI-Variable | CANONIZE_TOKEN, maskiert und geschützt |
| Ablauf | 2027-08-19 |
Wirksamkeit belegt, nicht angenommen (Pipeline 521, Wegwerf-Job, main unberührt):
Sichtbar: CANONIZE_TOKEN ist im Job gesetzt.
SCHREIBEN OK: Zweig canonize-token-probe-521 angelegt.
Aufgeraeumt: canonize-token-probe-521 wieder entfernt.
Der Job hat einen Wegwerf-Zweig angelegt und wieder gelöscht — damit ist gezeigt, dass der Wert im Job ankommt (geschützte Variable auf geschütztem Branch) und dass er schreiben darf. Der Prüf-Job ist danach wieder entfernt worden; es blieb kein Zweig liegen. Der erste echte Ernstfall ist die Rotation am 2026-09-01.
⚠️ Ein Ablaufdatum ist ein stiller Ausfall in der Zukunft. Am 2027-08-19 hört der Token auf zu gelten. Der Job läuft im Leerlauf trotzdem grün durch — auffallen würde es erst bei der nächsten echten Rotation danach, also frühestens am 2027-09-01. Genau die Klasse aus #0104. Gehört in den Kalender, nicht in die Hoffnung.
Zwei Fallen beim Prüfen, hier notiert weil sie beim nächsten Mal Zeit kosten würden:
Eine per API ausgelöste Pipeline hat die Quelle api, nicht web — die erste
Fassung der Regel übersprang den Job deshalb wortlos. Und dieses Repo kennt keine Stage
pruefen (das ist management); GitLab wies die Pipeline dafür komplett ab.