---
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.