# Pfadschema und Teamtrennung

<p class="callout info">Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026</p>

In OpenBao liegen Secrets in KV-Speichern (KV-v2-Mounts). Diese Seite erklärt, wo ein Secret hingehört und wer es lesen und schreiben darf. Wer die Regeln kennt, findet Secrets wieder und legt sie gleich an der richtigen Stelle ab.

<p class="callout warning">Gilt bisher nur im <strong>Lab</strong> (Lab-PoC). Für DEV und Produktion ist dasselbe Schema vorgesehen.</p>

## Ein Mount je Abteilung

Jede Abteilung hat einen eigenen Mount:

| Mount | Abteilung |
|---|---|
| `cci/` | Cloud Core Infrastructure (CCI) |
| `cpi/` | Container Platform Infrastructure (CPI) |
| `cpcs/` | Container Platform Core Services (CPCS) |
| `cpds/` | Container Platform DEXPRO Services (CPDS) |

## Pfade

Standardschema für alle Abteilungen außer CCI:

| Pfad | Wofür |
|---|---|
| `<abt>/<team>/<stage>/…` | Secrets eines Teams |
| `<abt>/shared/<stage>/…` | Secrets der ganzen Abteilung (`shared` ist als Teamname reserviert) |
| `<abt>/<team>/<stage>/nomad/<job>/…` | Secrets eines Nomad-Jobs |

CCI ist **ein** Team und gliedert sich deshalb nach Standort und Projekt:

| Pfad | Wofür |
|---|---|
| `cci/shared/<stage>/…` | für die ganze Abteilung, z. B. zentrale DNS- oder IPAM-Zugänge |
| `cci/<standort>/<stage>/shared/…` | für alle Projekte eines Standorts, z. B. `bremen1` |
| `cci/<standort>/<stage>/<projekt>/…` | nur für dieses Projekt |

`<stage>` ist immer der Branch-Name: `pre-development`, `development`, `staging` oder `production`. Das Lab nutzt `pre-development`.

## Woher Stage und Team kommen

- **Pipelines:** Die Stage ergibt sich aus dem Branch, auf dem die Pipeline läuft, das Team aus der GitLab-Gruppe des Projekts. Beides steckt im GitLab-JWT. An `production` kommen nur Pipelines auf geschützten Branches.
- **Menschen:** Das Team ergibt sich aus der Entra-Gruppe (in DEV, siehe Kapitel Anmeldung).
- **Nomad-Jobs:** Die Stage hängt am Nomad-Cluster, der Job am Job-Namen.

<p class="callout warning">Metadaten an einem Secret (<code>custom_metadata</code>) sind nur eine Beschriftung. Sie schützen nichts. Zugriff regeln allein Pfad und Policy.</p>

## Wer darf was

| | Lesen | Schreiben | Endgültig löschen |
|---|---|---|---|
| Team-Pipeline | eigener Teampfad und `shared/` der Abteilung | eigener Teampfad (`production` nur von geschützten Branches) | nein (nur Soft-Delete) |
| Mensch im Team | eigener Teampfad und `shared/` | eigener Teampfad und `shared/` | ja |
| Nomad-Job | nur `…/nomad/<job>/` | nein (Anlegen und Rotieren macht die Team-Pipeline) | nein |
| Globale OpenBao-Admins | alle KV-Mounts | alle KV-Mounts | ja |

Ausnahme CCI: Hier dürfen auch Pipelines in beide `shared`-Ebenen schreiben (Soft-Delete ja, endgültig löschen nein). Ein Projekt schreibt nur in seinen eigenen Projektpfad.

Die globalen Admins sind eine eigene Entra-Gruppe. Sie dürfen Secrets verwalten, aber OpenBao nicht konfigurieren (keine Policies, Anmeldeverfahren oder Mounts). Die Konfiguration entsteht als Code.

<p class="callout danger">Wer Policies oder Anmeldeverfahren schreiben darf, kann sich selbst jedes Recht geben. Diese Rechte gibt es deshalb nur für die Konfiguration als Code und das Admin-Token, nie für Teams.</p>

## Weiterführend

- [OpenBao: KV Secrets Engine Version 2](https://openbao.org/docs/secrets/kv/kv-v2/)
- [OpenBao: JWT/OIDC-Anmeldung](https://openbao.org/docs/auth/jwt/)