81 lines
3.1 KiB
Markdown
81 lines
3.1 KiB
Markdown
### Die Situation
|
||
|
||
Die Rolle generiert zwei Arten von Zertifikaten mit konfigurierbarer Laufzeit:
|
||
|
||
```yaml
|
||
nebula_ca_cert_duration: "87600h0m0s" # 10 Jahre (default)
|
||
nebula_client_cert_duration: "43800h0m0s" # 5 Jahre (default)
|
||
```
|
||
|
||
Es gibt keinen automatischen Erneuerungsmechanismus. Du musst manuell eingreifen – aber wie du vorgehst, hängt davon ab, was abläuft.
|
||
|
||
---
|
||
|
||
### Fall 1: Nur Host-Zertifikate laufen ab (CA noch gültig)
|
||
|
||
Das ist der einfache Fall. Die CA ist noch gültig, du brauchst nur neue Host-Certs.
|
||
|
||
**Vorgehen:**
|
||
1. Auf dem Primary Lighthouse die abgelaufenen Cert-Dateien löschen:
|
||
```bash
|
||
rm /opt/nebula/<hostname>.crt
|
||
rm /opt/nebula/<hostname>.key
|
||
```
|
||
2. Playbook normal ausführen – die Rolle erkennt die fehlenden Dateien und signiert neue Certs:
|
||
```bash
|
||
ansible-playbook -i inventory nebula.yml
|
||
```
|
||
|
||
Die `creates:`-Guards in `lighthouse_primary.yml` und `node.yml` prüfen nur ob die Datei existiert – wenn du sie löschst, werden sie neu erzeugt. Nebula auf den betroffenen Nodes wird automatisch neu gestartet (via Handler).
|
||
|
||
Du kannst auch selektiv nur bestimmte Hosts neu ausrollen:
|
||
```bash
|
||
ansible-playbook -i inventory nebula.yml --limit web01.example.com
|
||
```
|
||
|
||
---
|
||
|
||
### Fall 2: Das CA-Zertifikat läuft ab
|
||
|
||
Das ist der kritische Fall, weil ein neues CA-Zertifikat bedeutet: **alle Host-Zertifikate müssen ebenfalls neu signiert werden.** Ein altes Host-Cert, signiert von der alten CA, wird von Nebula abgelehnt sobald die neue CA verteilt ist.
|
||
|
||
Nebula unterstützt zwar das gleichzeitige Vertrauen in mehrere CAs (du kannst mehrere Zertifikate in `ca.crt` hinterlegen), aber die Rolle bildet das nicht ab. Der saubere Weg ist daher ein koordinierter Komplett-Rollout.
|
||
|
||
**Vorgehen:**
|
||
1. Auf dem Primary Lighthouse die CA-Dateien und alle Host-Certs löschen:
|
||
```bash
|
||
rm /opt/nebula/ca.crt
|
||
rm /opt/nebula/ca.key
|
||
rm /opt/nebula/*.crt
|
||
rm /opt/nebula/*.key
|
||
```
|
||
2. Playbook ausführen – neue CA wird erzeugt, alle Certs neu signiert und verteilt:
|
||
```bash
|
||
ansible-playbook -i inventory nebula.yml
|
||
```
|
||
|
||
Alternativ geht auch `nebula_clean_install: true`, das macht dasselbe, löscht aber zusätzlich die Binaries und den gesamten `/opt/nebula`-Ordner auf allen Hosts – meist unnötig.
|
||
|
||
---
|
||
|
||
### Wie erkennst du, wann Zertifikate ablaufen?
|
||
|
||
Die Rolle bringt kein Monitoring mit. Du hast zwei Optionen:
|
||
|
||
**Manuell prüfen** – auf dem Primary Lighthouse:
|
||
```bash
|
||
# CA-Zertifikat
|
||
/opt/nebula/nebula-cert print -path /opt/nebula/ca.crt
|
||
|
||
# Einen Node
|
||
/opt/nebula/nebula-cert print -path /opt/nebula/web01.example.com.crt
|
||
```
|
||
Im Output steht `Not After: 2034-...` – das ist das Ablaufdatum.
|
||
|
||
**Monitoring** – du könntest einen Ansible-Task oder ein Cron-Script bauen, das `nebula-cert print -json` aufruft und das Ablaufdatum gegen `now + X Tage` prüft. Die Rolle selbst macht das nicht.
|
||
|
||
---
|
||
|
||
### Empfehlung für die Praxis
|
||
|
||
Mit den Default-Werten (CA 10 Jahre, Hosts 5 Jahre) läuft das CA-Zertifikat nie zuerst ab. Trotzdem: **Trag beide Ablaufdaten in deinen Kalender ein**, sobald du das Netz ausgerollt hast. Ein abgelaufenes Nebula-Zertifikat bedeutet, dass alle Verbindungen stillschweigend abbrechen – ohne offensichtliche Fehlermeldung in den Anwendungslogs. |