Third party maintenance of Kubernetes applications

Wie kann ein externer Dienstleister Kubernetes‑Anwendungen zuverlässig betreiben, ohne unkontrollierten Zugriff auf Kundendaten, Secrets oder Clusterressourcen? Diese Arbeit entwickelt dafür eine kundenkontrollierte Architektur mit drei Schutzstufen für einen PostgreSQL‑Dienst.

Rahmen der Arbeit

Die Arbeit entwirft eine Zielarchitektur, keine produktionsreife Gesamtlösung. Sie entstand ohne reale Stakeholder oder Rohszenarien. Nicht untersucht werden Geschäftsmodelle, Vertragsrecht, Hardware- und Supply‑Chain‑Angriffe sowie kompromittierte Registry-, Cloud- oder CI/CD-Infrastrukturen. Redaktionsregeln erkennen zudem nur bekannte sensible Inhalte.

Ausgangslage

Kubernetes ermöglicht den Betrieb externer Software im Kundencluster. Das Fachwissen liegt oft beim Anbieter, die Verantwortung für Infrastruktur und Daten beim Kunden. Übernimmt ein Managed Service Provider (MSP) Releases und den laufenden Betrieb, benötigt er passende Rechte. Sie sollen Zuverlässigkeit ermöglichen, ohne unnötigen Einblick in Quellcode, Geschäftsdaten, Konfigurationen oder Secrets zu geben.

Zielsetzung und Vorgehen

Als Beispiel dient ein PostgreSQL‑Dienst mit CloudNativePG. Die Architektur trennt Release, Betrieb, Diagnose und Notfallzugriff. Acht Use Cases, elf konstante Rahmenbedingungen und 18 prüfbare Szenarien ermöglichen den Vergleich. Die Varianten Tief, Mittel und Hoch zeigen die Auswirkungen stärkerer Isolation auf Zusammenarbeit und Betriebsaufwand.

So greifen die wichtigsten Mechanismen ineinander

Release, Betrieb und Diagnose nutzen getrennte Identitäten unter Kundenkontrolle. Die Grafik lässt sich anklicken und vergrössern.

Drei Schutzstufen

• TiefDer MSP führt freigegebene Aktionen direkt über die Kubernetes‑Schnittstelle aus. Kundenseitige Regeln begrenzen die zulässigen Änderungen. Die Anwendung teilt Nodes mit anderen Workloads und verwendet Kubernetes Secrets.
• MittelEin kundenseitiger Controller prüft und vermittelt jeden Betriebsauftrag. Separate Nodes ermöglichen eine stärkere Trennung von anderen Workloads. Vault stellt kurzlebige Zugangsdaten bereit.
• HochEin vCluster stellt eine eigene virtuelle Kubernetes‑Schnittstelle bereit. Private Nodes und ein Secretless Broker schützen Laufzeit und Zugangsdaten. Bei vertretbarem Aufwand ergänzt eine Kata Runtime diese Trennung. Die Nachweise bleiben unter Kontrolle des Kunden.

Gemeinsame Schutzmassnahmen

Alle Varianten trennen Verantwortlichkeiten durch eigene Namespaces, Identitäten und Regeln unter Kundenkontrolle. Kundenseitige Vorgaben beschränken Netzwerkzugriffe und Speicheroptionen auf das Notwendige. Eine Service‑ID verknüpft Release, Betriebsaktion, Audit und Diagnose und macht Ereignisse eindeutig zuordenbar.

Für Notfälle kann der MSP zeitlich begrenzten Break‑Glass‑Zugriff beantragen. Der Kunde genehmigt ihn über Entra PIM. Teleport vermittelt und protokolliert die Sitzung und kann sie sofort beenden. Dauerhafte Zusatzrechte entstehen nicht.

Fazit

Die Arbeit vereint kontrollierten Release, begrenzten Betrieb, geschützte Diagnose und genehmigten Notfallzugriff. Der MSP bleibt handlungsfähig, während der Kunde Identitäten, Änderungen und Daten kontrolliert. Die drei Varianten zeigen die Abwägung zwischen Schutz und Betriebsaufwand. Beispielimplementierungen machen zentrale Kubernetes‑Grenzen konkret.

Wichtige Bausteine

• CloudNativePGSteuert den Betrieb des PostgreSQL‑Dienstes im Kubernetes‑Cluster
• FluxRollt freigegebene Änderungen aus dem Kundenrepository im Cluster aus
• ZugriffskontrollenRBAC und Admission legen fest, wer welche Änderungen vornehmen darf
• BetriebsauftragBeschreibt eine klar begrenzte Aktion für Mittel und Hoch
• OpenTelemetryBereitet Diagnosedaten auf, bevor der MSP sie erhält
• SecretsSchützen Zugangsdaten mit Kubernetes Secrets, Vault oder einem Secretless Broker
• Break‑GlassErmöglicht einen genehmigten, zeitlich begrenzten und aufgezeichneten Notfallzugriff

Projekt

26FS_IMVS15
Bachelorarbeit im Studiengang Informatik
Hochschule für Informatik FHNW

Team