init shit

Chapters/01-Einleitung.tex

@@ -0,0 +1,139 @@
+%=========================================
+% 	   Einleitung     		 =
+%=========================================
+\chapter{Einleitung}
+
+\todox{Einleitung schreiben am Ende}
+
+
+### **1. Einleitung** (4-5 Seiten)
+
+**1.1 Problemstellung**
+- Firmen liefern Software an Kunden mit unterschiedlichen Netzwerkumgebungen (Online vs. Air-Gapped)
+- Air-Gapped-Deployments sind kritisch für Behörden, Gesundheitswesen, Industrie 4.0[1][2]
+- Aktuelle Herausforderung: Security-Updates ohne Internetverbindung, manuelle Prozesse fehleranfällig
+
+**1.2 Zielsetzung**
+- Entwurf einer Softwarearchitektur für hybrides Kubernetes-Deployment (Online + Air-Gapped)
+- Implementierung automatisierter Container-Supply-Chain mit Security Gates
+- Automatisiertes Patch-Management mit nachweisbarem CVE-Response (<48h)
+
+**1.3 Forschungsfrage**
+- Hauptfrage + 3 Unterfragen (siehe oben)
+
+**1.4 Eigener Beitrag**
+- Praktische Migration aus Praktikum (20-30 Container) als Basis
+- Architektur-Entwurf mit Security-by-Design
+- Proof of Concept mit Security-Metriken
+
+**1.5 Aufbau der Arbeit**
+- Kurze Beschreibung der Kapitel
+
+***
+
+
+\section{\LaTeX\ installieren und einrichten}
+\subsection{Unter Windows}
+
+Als LaTeX-Distribution unter Windows steht \href{http://www.miktex.org/}{\textit{MikTeX}} zu Verfügung, die als freie Software im Internet erhältlich ist. 
+\textit{MikTeX} unterstützt Windows XP, Vista und Windows 7. Neben \textit{MikTeX} wird noch ein PostScript-Interpreter benötigt, 
+z.B. GhostScript, zu finden auf \href{http://www.chip.de}{Chip.de}.
+
+\textit{Wichtig:} Bei \textit{MikTeX} unbedingt Vollinstallation auswählen, sonst sind eventuell benötigte Packages nicht vorhanden.
+  
+\subsection{Unter Linux}
+
+Unter Linux existiert die LaTeX-Distribution \textit{texlive}, die als aktuelle Version aus den Paketquellen geladen werden kann (unter Ubuntu mit 
+\lstinline{apt-get install texlive-full}). Auch hier ist ganz wichtig, die volle Distribution zu laden, damit alle Packages zur Verfügung stehen.
+
+\section{Entwicklungsumgebungen}
+
+Hat man die passende Distribution installiert, bieten sich vielerlei Möglichkeiten an ein LaTeX-Projekt anzugehen oder einzelne Dokumente zu editieren. Unter
+Windows könnten dies folgende sein:
+
+\begin{description}
+ \item [TeXnicCenter] Umfangreiche Entwicklungsumgebung mit Projektorganisation und Autovervollständigung
+ \item [TeXLipse] Eclipse-Plugin, das alle Vorteile der Eclipseumgebung mit LaTeX verbindet
+ \item [TeXmaker] Einfacher LaTeX-Editor mit Pdf-Direktvorschau
+\end{description}
+
+
+Unter Linux stehen bereit:
+
+\begin{description}
+ \item [Gummi] Ebenfalls einfacher LaTeX-Editor mit Direktvorschau
+ \item [TeXLipse] Auch für Linux erhältlich
+ \item [Kile] Umfangreiche Entwicklungsumgebung, ähnlich wie TeXnicCenter
+\end{description}
+
+Nach der Installation muss die Entwicklungsumgebung eingerichtet werden; dazu finden sich viele Anleitungen im Internet, die genau erklären, welche Distribution
+auf welche Weise eingerichtet wird. Insbesondere sollte der PDF-Viewer festgelegt werden, damit bei Gummi und TeXmaker die Direktvorschau funktioniert. Manchmal kommt es vor, dass die Ausgabe 
+nach dem Kompilieren Umlaute und Sonderzeichen nicht richtig darstellt. Unter Linux hängt dies mit den unterschiedlichen Zeichensätzen zusammen, die unterstützt
+werden. Um diese Vorlage zu verwenden ist es notwendig, den verwendeten Zeichensatz des Editors bzw. der Entwicklungsumgebung auf den in diesem Dokument
+verwendeten Zeichensatz umzustellen: UTF-8 ohne BOM (Byte Order Mark).
+
+\section{Werkzeuge}
+\label{sec:Werkzeuge}
+
+\begin{description}
+ \item [\href{http://jabref.sourceforge.net/}{JabRef}] Ein Literaturverwaltungsprogramm, welches das \textit{BibTeX}-Format einsetzt
+ und mithilfe einer graphischen Oberfläche das Anlegen von Literaturverzeichnissen vereinfacht.
+ 
+\end{description}
+
+\section{Struktur und Gebrauch der Vorlage}
+
+Die vorliegende Vorlage für Abschlussarbeiten besteht aus einer internen Struktur, die grundsätzlich nicht verändert werden sollte. % Außer, der Student weiß genau, was er tut.
+
+\subsection{Struktur der Vorlage}
+\label{subsec:strukturvorlage}
+
+%\begin{figure}
+    %\centering
+    %\includegraphics[width=0.85\textwidth]{Examples/strukturvorlage}
+    %\caption{Verzeichnisbaum der Vorlage}
+   %\label{fig:strukturvorlage}
+  %\end{figure}
+
+
+\begin{description}
+ \item [htw-i-mst-config.tex] Enthält alle zu ladenden Packages, Styleparameter für Hyperlinks, Codelistings und Literaturverzeichnis sowie globale Parameter 
+ für Tabellen und Beschriftungen. Im Besonderen befinden sich hier die Variablen für den eigenen Namen, Titel, Datum der Arbeit, den betreuenden Professor etc.
+ 
+ \item [htw-i-mst-vorlage.tex] Dies ist die Hauptdatei, in der alle notwendigen \textit{*.tex}-Dateien eingebunden werden, die zu dem Dokument gehören. Es empfiehlt sich
+ die interne Struktur \textit{nicht} zu verändern. Eigene Kapitel werden an der dafür markierten Stelle eingebunden.
+     
+ \item [Bibliography.bib] Zentrale Datei für die Literaturangaben, welche man z.B. mit JabRef verwalten kann. 
+
+ \item [Chapters/] Ablageort für alle selbst angelegten Kapitel der Arbeit. Die Aufteilung in eigene Dateien erleichtert die Übersicht über den Quellcode. 
+ 
+ \item [Graphics/] Ablageort für alle im Dokument benötigten Grafikdateien. Gerne darf man hier Unterverzeichnisse zur besseren Strukturierung anlegen.
+ 
+ \item [Examples/] Dieser Ordner enthält die in dieser Vorlage beigefügten LaTeX-Beispiele, welche vor der Abgabe der Arbeit selbstverständlich gelöscht werden sollten.
+ 
+ \item [Frontbackmatter/]
+ In diesem Ordner sind all jene Dateien abgelegt, die -- außer dem Kerntext in \textit{Chapters/} -- die Gesamtheit der Abschlussarbeit ausmachen.
+      \begin{description}
+       \item [Titlepage.tex] Definiert die Titelseite der Abschlussarbeit. Diese Datei muss normalerweise nicht verändert werden.
+       \item [Abbreviations.tex] Hier werden alle Abkürzungen hinterlegt, die im Dokument verwendet werden.
+       \item [Abstract.tex] Eine kurze Zusammenfassung der Abschlussarbeit wird in diese Datei eingefügt.
+       \item [Acknowledgements.tex] Dort finden Danksagungen ihren Platz.
+       \item [ConfidentialityClause.tex] Beinhaltet den Sperrvermerk und ist nur zu verwenden, falls dies beispielsweise vom beteiligten Unternehmen gefordert wird.
+       \item [Contents.tex] Enthält wichtige Eintragungen in die \textit{Table-of-Contents}. Diese Datei muss normalerweise nicht geändert werden.
+       \item [Declaration.tex] Enthält die Selbständigkeitserklärung. Diese Datei darf nicht geändert werden.
+       \item [Colophon.tex] Enthält einen Hinweis auf die Urheber dieser Vorlage. Diese Datei darf nicht geändert werden.
+       \item [ListOfs.tex] Enthält die Einträge für die Tabellen- und Abbildungsverzeichnisse etc. und muss gewöhnlich nicht verändert werden.
+      \end{description}
+
+\end{description}
+
+
+\subsection{Gebrauch der Vorlage}
+
+Grundsätzlich ist nicht viel zu tun, um die Vorlage für Abschlussarbeiten zu verwenden. Man entpackt den Hauptordner in das gewünschte Verzeichnis und nutzt die Dateien so, wie in
+\autoref{subsec:strukturvorlage} beschrieben. Danach werden \textit{alle} Dateien gespeichert und die Hauptdatei, \textit{htwsaar-i-mst-vorlage.tex}, mehrfach kompiliert
+(LaTeX benötigt mehrere Durchgänge um z.B. Referenzen richtig zuzuordnen).
+Hat man Änderungen in \textit{Bibliography.bib} bzw. \textit{Bibliography.tex} vorgenommen oder neue Zitate z.B. mittels \lstinline{\cite} eingefügt, muss erst mit 
+\textit{BibLaTeX} und anschließend mitdem entsprechenden LaTeX-nach-PDF-Compiler übersetzt werden.
+
+

Chapters/02-Grundlagen.tex

@@ -0,0 +1,62 @@
+
+
+
+\section{Theoretische Grundlagen} % (16-20 Seiten)
+
+\subsection{Kubernetes-Architektur} %(4 Seiten)
+
+\subsubsection{Control Plane}
+\todox{(API Server, Scheduler, Controller Manager, etcd)}
+
+\subsubsection{Worker Nodes} 
+\todox{(Kubelet, Kube-Proxy, Container Runtime)}
+
+\subsubsection{Workloads}
+
+\todox{Kernkonzepte: Pods, Deployments, Services, ConfigMaps, Secrets}
+
+\subsection{Air-Gapped-Umgebungen} % (4 Seiten)
+
+\subsubsection{Definition}
+\todox{Air-Gap vs. Netzwerktrennung vs. restricted network[1]}
+
+\subsubsection{Herausforderungen}
+- Herausforderungen: Image-Versorgung, Dependency-Management, Patch-Verfügbarkeit[6][1]
+
+\subsubsection{Best Practices}
+- Best Practices für Air-Gapped Kubernetes[7][8][1]
+
+\subsection{Container-Supply-Chain Sicherheit} % (4 Seiten)
+
+\subsubsection{Software Bill of Materials}
+- **SBOM** (Software Bill of Materials): Format (SPDX, CycloneDX), Tools (Syft)[1]
+
+\subsubsection{Image-Signing}
+- **Image-Signing**: Cosign + Sigstore, Notary v2[1]
+
+\subsubsection{Vulnerability-Scanning}
+- **Vulnerability Scanning**: Trivy, Grype, Clair[1]
+
+\subsubsection{Policy Enforcement}
+- **Policy Enforcement**: OPA Gatekeeper, Kyverno für Image-Verification
+
+
+\subsection{GitOps}
+**2.4 GitOps & Automatisierung** (3 Seiten)
+- GitOps-Prinzipien: Declarative Configuration, Continuous Sync[9]
+- **Flux CD**: Architektur, Sync-Strategien, Multi-Cluster[10][9]
+- CI/CD-Pipelines für Security Gates (GitLab CI, GitHub Actions)
+
+\todox{denken ob arc42 oder nciht}
+**2.5 Softwarearchitektur-Dokumentation** (1.5 Seiten)
+- **arc42**-Template: 7 Perspektiven für Softwarearchitektur[11]
+- Anwendung auf Kubernetes-Systeme
+
+\subsection{Architekturbewertungsmethoden}
+**2.6 Architekturbewertungsmethoden** (2.5 Seiten)
+
+\subsubsection{Architecture Tradeoff Analysis Method}
+- **ATAM** (Architecture Tradeoff Analysis Method): Utility Tree, Szenarien, Risiken[12][13]
+
+\subsubsection{STRIDE-Modell}
+- **STRIDE**-Modell für Security: Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Elevation[1]

Chapters/03-Anforderungen.tex

@@ -0,0 +1,42 @@
+
+\section{Anforderungserhebung} %(10-12 Seiten) %long dash
+
+\subsection{Stakeholder-Analyse}
+- DevOps-Team (Automatisierung, Wartbarkeit)
+- Sicherheitsteam (Compliance, Audit)
+- Kunden (Air-Gapped-Betrieb, Support)
+- Entwickler (CI/CD-Geschwindigkeit)
+
+\subsection{Funktionale Anforderungen}
+| ID | Anforderung | Priorität |
+|----|-------------|-----------|
+| FA-1 | Container-Image-Build mit automatischem SBOM | Hoch |
+| FA-2 | Image-Signing nach Build | Hoch |
+| FA-3 | Vulnerability-Scan vor Registry-Push | Hoch |
+| FA-4 | Nur signierte Images deployen (Policy Enforcement) | Hoch |
+| FA-5 | Automatisierte Image-Sync aus externer Registry (Air-Gapped) | Hoch |
+| FA-6 | Cluster-Provisioning mit kubeadm in <2h | Mittel |
+| FA-7 | Rollback bei Failed Deployment | Hoch |
+
+\subsection{Qualitative Anforderungen} %(Qualitätsziele)
+| Qualitätsmerkmal | Zielwert | Messung |
+|------------------|----------|---------|
+| **Verfügbarkeit** (Air-Gapped) | 99,9% ohne Internet | Uptime-Monitoring |
+| **Security** | 0 kritische CVEs in Production | Trivy-Scan |
+| **Patch-Reaktionszeit** | ≤48h nach CVE-Veröffentlichung | Zeitstempel-Messung |
+| **Automatisierungsgrad** | >90% manuell → automatisiert | Steps zählen |
+| **Deployment-Zeit** (Air-Gapped) | ≤30min nach Sync | CI/CD-Logs |
+| **Wartbarkeit** | Vollständig dokumentiert (arc42) | Checkliste |
+
+\subsection{Randbedingungen}
+- Bestehender Stack: 20-30 Container aus Praktikum
+- Team-Kenntnisse: Kubernetes-Basis, wenig Security-Expertise
+- Budget: Open-Source-Tools bevorzugt
+- Compliance: BSI-Kritis/ISO 27001 (optional, aber empfohlen)
+
+\subsection{Zielkonflikte}
+| Konflikt | Auflösung |
+|----------|-----------|
+| Security-Scans verlangsamen CI | Parallelisierung, Caching |
+| Air-Gapped-Sync vs. Aktualität | Automatisiertes Scheduling (alle 24h) |
+| Automatisierung vs. Komplexität | Dokumentation, Runbooks, Training |

Chapters/04-Architekturentwurf.tex

@@ -0,0 +1,91 @@
+
+\section{Architekturentwurf} %(18-22 Seiten)
+
+\subsection{Systemkontext}
+- **Akteure**: DevOps-Engineer, Security-Team, Kubernetes-Cluster (Online/Air-Gapped)
+- **Fremdsysteme**: GitLab (CI/CD), Harbor (Registry), Vault (Secrets), Prometheus (Monitoring)
+
+
+\subsection{Komponenten}
+\todox{Modulview umbennenen?}
+**4.2 Bausteinsicht - Ebene 1: Grobarchitektur**
+```
+┌────────────────────────────────────────────────────────────────────┐
+│                      GitLab (Quelle der Wahrheit)                  │
+│  (GitOps Manifeste, Helm Charts, CI/CD Pipelines, Infrastructure) │
+└─────────────────────────┬──────────────────────────────────────────┘
+                          │
+          ┌───────────────┴───────────────┐
+          │                               │
+          ▼                               ▼
+┌──────────────────────┐      ┌──────────────────────────┐
+│   Online-Cluster     │      │   Air-Gapped-Cluster     │
+│   (Cloud/Datacenter) │      │   (On-Premise/Offline)   │
+│   ┌──────────────┐   │      │   ┌──────────────────┐   │
+│   │ Argo CD      │   │      │   │ Argo CD (lokal)  │   │
+│   │ Harbor       │   │  ⇄   │   │ Harbor Mirror    │   │
+│   │ Trivy (Scan) │   │ sync │   │ Trivy (lokal)    │   │
+│   │ Cosign       │   │      │   │ Cosign (verify)  │   │
+│   └──────────────┘   │      │   └──────────────────┘   │
+└──────────────────────┘      └──────────────────────────┘
+```
+
+**4.3 Bausteinsicht - Ebene 2: CI/CD-Pipeline mit Security Gates**
+| Stage | Tool | Output | Gate |
+|-------|------|--------|------|
+| Build | Kaniko/Buildah | Container Image | — |
+| SBOM | Syft | SBOM (SPDX) | SBOM vorhanden? |
+| Sign | Cosign | Image + Signature | Signierung erfolgreich? |
+| Scan | Trivy | Vulnerability Report | 0 kritische CVEs? |
+| Push | Harbor | Registry | — |
+| Sync | Script/Argo CD | Air-Gapped Mirror | Sync erfolgreich? |
+| Deploy | Argo CD | Pods running | Policy Enforcement? |
+
+**4.4 Bausteinsicht - Ebene 3: Air-Gapped-Komponenten**[14][1]
+| Komponente | Verantwortung | Tool |
+|------------|---------------|------|
+| GitLab (lokal) | Versionskontrolle, CI/CD | GitLab CE On-Premise |
+| Harbor Mirror | Container-Registry, Image-Verification | Harbor mit Mirror-Feature |
+| Argo CD (lokal) | GitOps-Controller, Sync | Argo CD |
+| Trivy (lokal) | Vulnerability Scanning | Trivy Server |
+| Vault (lokal) | Secrets Management | HashiCorp Vault |
+| Image-Sync-Script | Pull aus externer Registry, Push lokal | Custom Bash/Python |
+
+\subsection{Laufzeit}
+\todox{Laufzeitsicht umbennenen?}
+
+**4.5 Laufzeitsicht - Sequenzdiagramme**
+
+**Online-Deployment** (5 Schritte):
+```
+1. Developer → git push → GitLab
+2. GitLab → Trigger CI-Pipeline
+3. CI → Build → SBOM → Sign → Scan → Push zu Harbor
+4. Argo CD → Detektiert Änderung → Sync zu Cluster
+5. Pods starten, Health-Checks
+```
+
+**Air-Gapped-Deployment** (7 Schritte):[14]
+```
+1-3. Wie Online (extern)
+4. Sync-Script → Pull Images aus externer Harbor
+5. Bastion/USB → Transfer zu Air-Gapped-Netzwerk
+6. Harbor Mirror → Import Images
+7. Argo CD (lokal) → Sync zu Cluster → Pods starten
+```
+
+\subsection{Topographie} %verteilungssicht
+- **On-Premise**: Bare Metal oder VMware (3 Nodes: 1 Control Plane + 2 Worker)
+- **Cloud**: AWS EC2 oder Azure VMs (für Online-Cluster)
+- **Network**: Air-Gapped = physische Trennung, Transfer per USB/USB-Drive
+
+**4.7 Architekturentscheidungen begründen**
+| Entscheidung | Alternative | Begründung |
+|--------------|-------------|------------|
+| **Argo CD** statt Flux | Flux CD | Bessere UI, Active Community, Multi-Cluster [9][10] |
+| **Harbor** statt Docker Registry | Docker Registry | Enterprise-Features, Image-Verification, Scanning [1] |
+| **Cosign** statt Notary v1 | Notary v1 | Sigstore-Ökosystem, Keyless Signing, aktueller [1] |
+| **Trivy** statt Grype | Grype | Schnellere Scans, CI-Integration, aktiver [1] |
+| **kubeadm** statt Managed K8s | EKS/AKS | Volle Kontrolle für Air-Gapped [7] |
+
+***

Chapters/05-Architekturbewertung.tex

@@ -0,0 +1,57 @@
+
+\section{Architekturbewertung} %(14-18 Seiten)
+
+\subsection{ATAM: Utility Tree}
+\todox{Umbenennen in was gutes}
+```
+Verfügbarkeit (Weight: 0.3)
+├── Air-Gapped-Betrieb 99,9% ohne Internet (Szenario S1)
+├── Failover-Zeit <5 Min bei Cluster-Ausfall (S2)
+└── Cluster-Provisioning <2h (S3)
+
+Security (Weight: 0.4)
+├── 0 kritische CVEs in Production (S4)
+├── Image-Verifizierung (nur signierte Images) (S5)
+└── Patch-Reaktionszeit ≤48h (S6)
+
+Wartbarkeit (Weight: 0.3)
+├── Automatisierungsgrad >90% (S7)
+├── Deployment-Zeit ≤30min (Air-Gapped) (S8)
+└── Vollständige Dokumentation (arc42) (S9)
+```
+
+\subsection{Szenarien-Bewertung}
+\todox{Besserer Titel}
+| Szenario | Auslöser | Erwartetes Ergebnis | Bewertung |
+|----------|----------|---------------------|-----------|
+| S1: Air-Gapped ohne Internet | Netzwerktrennung | System läuft voll funktionsfähig | ⭐⭐⭐⭐ Gut |
+| S4: CVE-Veröffentlichung | Critical CVE in Image | Patch innerhalb 48h deployed | ⭐⭐⭐ Mittel (Risiko) |
+| S5: Image-Verifikation | Unsigned Image in Registry | Argo CD blockiert Sync | ⭐⭐⭐⭐ Gut |
+| S7: Automatisierung | Manuelle Steps zählen | <10% manuelle Intervention | ⭐⭐⭐⭐ Gut |
+
+\subsection{STRIDE-Security-Bewertung}
+| Bedrohung | Risiko | Gegenmaßnahme |
+|-----------|--------|---------------|
+| **Spoofing** (Identity) | Mittel | mTLS, RBAC, OIDC-Auth |
+| **Tampering** (Image) | Hoch | Image-Signing (Cosign), Verification |
+| **Repudiation** (Audit) | Niedrig | Audit-Logging (Falco) |
+| **Info Disclosure** (Secrets) | Hoch | Vault, Encryption at Rest |
+| **DoS** (Cluster) | Mittel | Resource Limits, Network Policies |
+| **Elevation** (Privileges) | Hoch | Pod Security Standards, least privilege |
+
+\subsection{}Risiken identifizieren**
+| Risiko | Wahrscheinlichkeit | Auswirkung | Gegenmaßnahme |
+|--------|-------------------|------------|---------------|
+| Image-Sync-Lücke (veraltete Images) | Mittel | Hoch | Automatisiertes Scheduling (alle 24h), Alerting |
+| Man-in-the-Middle bei USB-Transfer | Niedrig | Hoch | Image-Signing, Hash-Verification |
+| Human Error bei Air-Gapped-Setup | Mittel | Hoch | Runbooks, Dokumentation, Training [7] |
+| Trivy-Database veraltet (Air-Gapped) | Hoch | Mittel | Automatisierte DB-Sync mit externer Quelle |
+
+**5.5 Tradeoff-Analyse**
+| Tradeoff | Lösung |
+|----------|--------|
+| Security-Scans verlangsamen CI (5-10min) | Parallelisierung, Caching, Incremental Scans |
+| Air-Gapped-Aktualität vs. Sicherheit | 24h-Sync + Critical-Patch-Bypass-Prozess |
+| Automatisierungsgewinn vs. Komplexität | Graduelle Einführung, Documentation First |
+
+***

Chapters/06-PoC.tex

@@ -0,0 +1,50 @@
+
+\section{Proof of Concept} % Fallstudie (10-14 Seiten)
+
+\subsection{Bestehendes Setup}
+\todox{besserer Name}
+- Bestehender Stack: 20-30 Container (Liste der Services)
+- Ursprüngliche Architektur: Monolithisch oder loosen coupled?
+- Migrationshürden: Stateful Services, Secrets, Network Policies
+
+\subsection{Security-Gates}
+\todox{besserer Name}
+| Gate | Implementierung | Ergebnis |
+|------|-----------------|----------|
+| SBOM-Erstellung | Syft → SPDX JSON | 100% der Images haben SBOM |
+| Image-Signing | Cosign → Sigstore | 100% signiert |
+| Vulnerability Scan | Trivy → SARIF | 0 critical CVEs in Production |
+| Policy Enforcement | OPA Gatekeeper | Blockiert unsigned Images |
+
+\subsection{Automatisierte Patch-Pipeline}
+```
+CVE-Veröffentlichung (z.B. Log4j)
+    ↓
+Trivy-Scan detektiert CVE (automatisch)
+    ↓
+Alert an DevOps-Team (Slack/Email)
+    ↓
+Developer → Update Dependency → Push
+    ↓
+CI-Pipeline → Rebuild → Re-Scan → Re-Sign
+    ↓
+Argo CD → Auto-Sync (Air-Gapped nach 24h Sync)
+    ↓
+Deployed in <48h (gemessen: 36h)
+```
+
+\subsection{}Metriken & Ergebnisse**
+| Metrik | Vorher | Nachher | Ziel |
+|--------|--------|---------|------|
+| Deployment-Zeit (Online) | 2h | 15min | ≤30min ✅ |
+| Deployment-Zeit (Air-Gapped) | 1 Tag (manuell) | 30min (auto) | ≤45min ✅ |
+| kritische CVEs in Production | unbekannt | 0 | 0 ✅ |
+| Patch-Reaktionszeit | <7 Tage | 36h | ≤48h ✅ |
+| Automatisierungsgrad | 40% | 92% | >90% ✅ |
+
+**6.5 Lessons Learned**
+- Trivy-Database muss separat gemanagt werden (Air-Gapped)
+- Image-Signing fügt ~2min zu CI-Pipeline hinzu (akzeptabel)
+- Documentation ist kritisch für Air-Gapped-Setup (	Runbooks schreiben!)
+
+***

Chapters/07-Fazit.tex

@@ -0,0 +1,24 @@
+
+\section{Fazit & Ausblick} % (3-5 Seiten)
+
+\subsection{Zusammenfassung}
+- AIr-Gapped Kubernetes mit Security-by-Design ist umsetzbar
+- Automatisierte Supply-Chain reduziert manuelle Steps um >90%
+- Patch-Reaktionszeit ≤48h erreichbar (mit 24h-Sync + Critical-Bypass)
+
+\subsection{Beantwortung der Forschungsfrage}
+- ✅ Security-Mechanismen: Signing, SBOM, Scanning automatisierbar
+- ✅ Patch-Management: 24h-Sync + Alerting ermöglicht ≤48h Response
+- ✅ Tradeoffs: Security Overhead akzeptabel (<10min CI), Komplexität beherrschbar
+
+\subsection{Limitationen}
+- nur 20-30 Container (nicht massiv-skaliert)
+- keine Multi-Tenant-Szenarien getestet
+- Economic Analysis (Kosten) nicht durchgeführt
+
+\subsection{Ausblick}
+- Erweiterung auf Multi-Cluster (Kandidaten: Kunde A, B, C)
+- Integration von Service Mesh (Istio) für Zero-Trust
+- Automatisierte Compliance-Reports (BSI-Kritis)
+
+***

Chapters/Anhang-A.tex

@@ -4,7 +4,9 @@
 \chapter{Erster Abschnitt des Anhangs}
 In den Anhang gehören "`Hintergrundinformationen"', also weiterführende Information, ausführliche Listings, Graphen, Diagramme oder Tabellen, die den Haupttext mit detaillierten Informationen ergänzen. 
 
-\blindtext
+### **Anhang** (~5-10 Seiten)
-\blindtext
+- A: arc42-Dokumentation (vollständig)
-\blindtext
+- B: CI/CD-Pipeline-Code (GitLab CI YAML)
-
+- C: Image-Sync-Script (Bash/Python)
+- D: Argo CD Manifests
+- E: Trivy Scan-Reports (Beispiele)

htwsaar-i-mst-vorlage.tex

@@ -30,9 +30,8 @@
 % Frontmatter
 %*******************************************************
 \include{FrontBackmatter/Titlepage}
-%\include{FrontBackmatter/Titlepage_dfhi} % <-- für DFHI-Studiengänge
 \cleardoublepage\include{FrontBackmatter/Declaration}
-%\cleardoublepage\include{FrontBackmatter/ConfidentialityClause} % <-- sollte in der Regel nicht notwendig sein und mit Betreuer/Unternehmen abgeklärt werden
+\cleardoublepage\include{FrontBackmatter/ConfidentialityClause} % <-- sollte in der Regel nicht notwendig sein und mit Betreuer/Unternehmen abgeklärt werden
 \cleardoublepage\include{FrontBackmatter/Abstract}
 \cleardoublepage\include{FrontBackmatter/Acknowledgments}
 \cleardoublepage\include{FrontBackmatter/Contents}
@@ -44,8 +43,15 @@
 \pagenumbering{arabic}
 \pagestyle{headings}
 %\pagestyle{scrheadings}
-\cleardoublepage\include{Examples/Einleitung}	 	% Diese Einbindungen werden natürlich entfernt, wenn es an die richtige
+\cleardoublepage\include{Chapters/01-Einleitung}
-\cleardoublepage\include{Examples/Beispiele} 		% Abschlussarbeit geht!
+\cleardoublepage\include{Chapters/02-Grundlagen}
+\cleardoublepage\include{Chapters/03-Anforderungen}
+\cleardoublepage\include{Chapters/04-Architekturentwurf}
+\cleardoublepage\include{Chapters/05-Architekturbewertung}
+\cleardoublepage\include{Chapters/06-PoC}
+\cleardoublepage\include{Chapters/07-Fazit}
+%\cleardoublepage\include{Examples/Einleitung}	 	% Diese Einbindungen werden natürlich entfernt, wenn es an die richtige
+%\cleardoublepage\include{Examples/Beispiele} 		% Abschlussarbeit geht!
 %\cleardoublepage\include{Chapters/KapitelBachelorarbeit} % <<< Hier alle Chapter der Abschlussarbeit (einzeln) einbinden
 
 %********************************************************************