[LAYER_3] GitOps & SSoT: Das Ende der manuellen CLI-Frickelei

[LAYER_3] GitOps & SSoT: Das Ende der manuellen CLI-Frickelei

Wer in einer KRITIS-Umgebung heute noch per SSH auf Switche geht, um "mal eben" ein VLAN zu ändern, hat die Kontrolle über seine Governance bereits verloren. Manuelle Eingriffe sind nicht auditierbar, fehleranfällig und der natürliche Feind jeder Zertifizierung. Für Project Sentinel haben wir Layer 3 als Governance Plane deklariert: Hier wird der Soll-Zustand definiert.

NetBox: Das digitale Gehirn (SSoT)

Das Herzstück unserer Automatisierung ist NetBox v4.5.3. In dieser Architektur fungiert NetBox nicht als einfaches IPAM-Tool, sondern als die Single Source of Truth (SSoT).

Was nicht in der NetBox steht, existiert im Netzwerk nicht. Punkt.

  • Provisionierung via Terraform: Anstatt die NetBox-Oberfläche zu klicken, nutzen wir den modernisierten Provider e-breuninger/netbox (v5.6.x). Wir definieren Präfixe, VLANs und IP-Adressen als Terraform-Ressourcen.
  • Vorteil: Jede Änderung am Datenmodell ist versioniert und lässt sich per terraform plan vorab validieren.

Die GitLab Pipeline: Das Fließband der Infrastruktur

Sobald der Soll-Zustand in der NetBox definiert ist, übernimmt der GitLab Runner auf unserem Management-Host (MGMT-01, Ubuntu 24.04).

Der Workflow ist kompromisslos automatisiert:

  1. Commit & Push: Der Architekt pusht Änderungen am Terraform-Code oder den Ansible-Playbooks.
  2. Validation: Die Pipeline fängt den Job ab und installiert benötigte Collections in einem flüchtigen Container.
  3. Enforcement: Ansible zieht sich die Live-Daten aus der NetBox-API und rollt den Zustand auf die Cisco-Nexus-Spines, Aruba-Leafs und die FortiGate aus.

Lessons Learned: YAML-Parser-Voodoo & Portkollisionen

Im Maschinenraum der Automatisierung stößt man auf Probleme, die in keinem Handbuch stehen. Zwei Highlights aus dem Layer 3 Deployment:

1. Das YAML-Escape-Problem

Beim Bau der GitLab-Pipeline stießen wir auf einen syntaktischen Fehler im Parser. Auslöser war ein Doppelpunkt im HTTP-Authorization-Header innerhalb eines curl-Aufrufs.

  • Die Lösung: Komplette Einkapselung des Aufrufs in einfache Anführungszeichen ('...'), um dem Parser die Interpretation technischer Sonderzeichen zu entziehen. Ein kleiner Fix mit großer Wirkung für die Pipeline-Stabilität.

2. L4-Port-Conflict

Standardmäßig wollten sowohl NetBox als auch ChromaDB (Layer 5) den Port 8000 auf dem Host belegen.

  • Die Lösung: Ein deterministisches Mapping. Wir haben den Host-Port von ChromaDB konsequent auf 8001:8000 umgebogen. Port-Hygiene ist die Basis für einen sauberen Stack.

Fazit Layer 3

Durch die Kombination aus NetBox und GitLab CI/CD haben wir den "RTO nahe Null" erreicht. Sollte die Fabric ausfallen, stellen wir das komplette Netzwerkmodell in Sekunden deklarativ wieder her. Wir haben eine Infrastruktur geschaffen, die zu 100 % Audit-Ready für NIS-2 und ISO 27001 ist.

Nächster Halt: In Teil 4 kümmern wir uns um das Nervensystem – Identity (Layer 4). Wir schauen uns an, wie wir Keycloak und OIDC nutzen, um den Zugriff auf all diese mächtigen Tools abzusichern.

Status: Governance Established. Infrastructure as Code Operational.


Read more

[CASE_STUDY] Air-Gapped AI & Zero-Trust: Die Architektur der Souveränität

[CASE_STUDY] Air-Gapped AI & Zero-Trust: Die Architektur der Souveränität

In hochregulierten kritischen Infrastrukturen (KRITIS), insbesondere unter dem Druck der NIS-2-Richtlinie, ist der Einsatz von Public-Cloud-KI (OpenAI, MS Copilot) kein bloßes Effizienzthema mehr – es ist ein unkalkulierbares Informationssicherheits-Risiko. Wer sensible Netzwerkkonfigurationen, Passwörter oder Topologien über externe APIs schickt, begeht Compliance-Suizid. Dieser Bericht dokumentiert den Gegenentwurf: Project Sentinel. Eine vollkommen autarke,

By Dieter Bänisch