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>
82 lines
3.9 KiB
Markdown
82 lines
3.9 KiB
Markdown
---
|
|
type: issue
|
|
id: "0084"
|
|
status: done
|
|
created: 2026-08-02
|
|
milestone: M1
|
|
priority: medium
|
|
due: 2026-09-01
|
|
projekt: gitops
|
|
gitlab_iid: "51"
|
|
related: []
|
|
---
|
|
# CI: CANONIZE_TOKEN für die automatische TURN-Rotation hinterlegen
|
|
|
|
> Adoptiert aus [gitops#51](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/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)
|
|
|
|
1. *Settings → Access Tokens* in diesem Projekt: Token anlegen
|
|
- Name z. B. `canonize-rotation`
|
|
- Rolle **Maintainer** (nötig, weil `main` protected ist)
|
|
- Scope **`write_repository`** — mehr nicht
|
|
- Ablauf: setzen und im Kalender vormerken, sonst steht der Job irgendwann still
|
|
2. *Settings → CI/CD → Variables*: Variable **`CANONIZE_TOKEN`** mit 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.
|