Seminar Cloud&Heat Titan / SecuStack – Kompaktseminar Grundlagen, Betrieb und Sicherheit

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Kompaktseminar vermittelt in drei Tagen einen strukturierten Gesamtüberblick über Architektur, OpenStack, Kubernetes, Yaook, Monitoring, Backup und Sicherheit. Es ist für Rollen vorgesehen, die ein belastbares Verständnis der Plattform benötigen, ohne jedes Spezialthema in voller Tiefe zu behandeln.

Lernziele

• Aufbau und Verantwortungsgrenzen der Plattform erklären
• OpenStack-Ressourcen und zentrale Bedienwege sicher einordnen
• Kubernetes- und Yaook-Zustände für den Betrieb lesen
• Monitoring-, Backup- und Störungsprozesse beurteilen
• wesentliche Härtungs- und Schutzmaßnahmen priorisieren

Zielgruppe und Voraussetzungen

Zielgruppe: Technische Projektleitung, Plattformadministration, IT-Architektur, Security-Verantwortung, Service Management und erfahrene Systemadministration.

Voraussetzungen: Grundkenntnisse in Linux, Virtualisierung und IP-Netzen. Produktspezifische Vorkenntnisse sind nicht erforderlich.

Seminarinhalte

Tag 1: Architektur und OpenStack-Grundlagen

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Einordnung von Titan und SecuStack

Die Einheit ordnet die Plattform als vorkonfigurierte, skalierbare On-Premises-Cloud für souveräne und besonders geschützte Betriebsmodelle ein.

1. Schritt 1 – Anwendungsfall abgrenzen: Schutzbedarf, Datenlokation, Verfügbarkeitsziel und erforderliche Offline-Fähigkeit werden als belastbare Rahmenbedingungen erfasst.
2. Schritt 2 – Leistungsumfang strukturieren: Hardware, Cloud-Plattform, Betriebswerkzeuge, Sicherheitsfunktionen und optionale Betriebsleistungen werden voneinander abgegrenzt.
3. Schritt 3 – Betriebsmodell zuordnen: Eigenbetrieb, unterstützter Betrieb und vollständig betreute Varianten werden anhand von Verantwortlichkeiten und Reaktionszeiten verglichen.
4. Schritt 4 – Zielbild dokumentieren: Die gewählte Ausbaustufe wird mit Annahmen, Abhängigkeiten, offenen Entscheidungen und Abnahmekriterien festgehalten.

Praxisbezug: Erstellung eines kompakten Zielbilds für einen beispielhaften KRITIS-nahen oder souveränen On-Premises-Einsatz.

Referenzarchitektur und Schichtenmodell

Die Plattform wird in physische Infrastruktur, Kubernetes- und Operator-Ebene, OpenStack-Dienste, Sicherheitsfunktionen und Betriebsprozesse zerlegt.

1. Schritt 1 – Schichten identifizieren: Rack, Compute, Storage, Netzwerk, Management, Kubernetes, Yaook-Operatoren und OpenStack-Dienste werden in einer Gesamtübersicht verortet.
2. Schritt 2 – Abhängigkeiten erfassen: Steuerungs-, Daten- und Verwaltungswege werden zwischen den Schichten nachvollzogen und kritische Kopplungen markiert.
3. Schritt 3 – Fehlerdomänen bilden: Ausfallbereiche für Strom, Kühlung, Netzwerk, Hosts, Cluster-Komponenten und Plattformdienste werden systematisch getrennt.
4. Schritt 4 – Architektur bewerten: Redundanz, Wartbarkeit, Skalierbarkeit und Sicherheitszonen werden gegen die zuvor definierten Anforderungen geprüft.

Praxisbezug: Aufbau eines Architekturdiagramms mit Schichten, Schnittstellen, Vertrauensgrenzen und Fehlerdomänen.

OpenStack-Service- und Ressourcenmodell

Die zentralen OpenStack-Dienste werden als zusammenhängende Steuerungsebene für Identität, Compute, Netzwerk, Images und Storage eingeordnet.

1. Schritt 1 – Dienste zuordnen: Keystone, Nova, Neutron, Glance, Cinder, Horizon und ergänzende Dienste werden nach Aufgabe und Schnittstelle klassifiziert.
2. Schritt 2 – Ressourcenbeziehungen lesen: Projekt, Benutzer, Rolle, Netzwerk, Subnetz, Port, Image, Flavor, Volume und Instanz werden in ihrer Abhängigkeit dargestellt.
3. Schritt 3 – API-Wege nachvollziehen: Authentifizierung, Servicekatalog, Token-Nutzung und nachfolgende API-Aufrufe werden als vollständige Transaktion betrachtet.
4. Schritt 4 – Betriebsgrenzen erkennen: Mandantenaufgaben, Plattformaufgaben und Infrastrukturaufgaben werden voneinander abgegrenzt.

Praxisbezug: Aufbau eines Ressourcenmodells für die Bereitstellung einer virtuellen Maschine mit Netzwerk und persistentem Volume.

Tag 2: Kubernetes, Yaook und Betriebsüberwachung

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Kubernetes-Grundlagen für den Plattformbetrieb

Kubernetes stellt die Orchestrierungsebene für die OpenStack-Kontrolldienste und die zugehörigen Operatoren bereit.

1. Schritt 1 – Objekte einordnen: Namespaces, Pods, Deployments, StatefulSets, Services, Jobs, ConfigMaps und Secrets werden nach Funktion unterschieden.
2. Schritt 2 – Zustand lesen: Desired State, aktueller Status, Conditions, Events und Controller-Verantwortung werden systematisch ausgewertet.
3. Schritt 3 – Scheduling verstehen: Node Labels, Taints, Affinitäten, Ressourcenanforderungen und PodDisruptionBudgets werden auf Platzierung und Verfügbarkeit bezogen.
4. Schritt 4 – Basisdiagnose durchführen: Podstatus, Logs, Events, Endpunkte und Ressourcenverbrauch werden in fester Reihenfolge geprüft.

Praxisbezug: Analyse einer Beispielanwendung mit Deployment, Service, ConfigMap, Secret und gestörtem Pod.

Yaook-Operatoren und deklarativer Betrieb

Yaook nutzt Kubernetes-Operatoren, um OpenStack-Dienste deklarativ bereitzustellen und fortlaufend auf den gewünschten Zustand abzugleichen.

1. Schritt 1 – Custom Resources identifizieren: Dienstspezifische Ressourcen und ihre Spezifikation werden den erzeugten Kubernetes-Objekten zugeordnet.
2. Schritt 2 – Reconciliation verfolgen: Änderung, Operator-Reaktion, erzeugte Teilressourcen und Statusbedingungen werden über mehrere Schleifen beobachtet.
3. Schritt 3 – Abhängigkeiten lesen: Datenbanken, Message Queues, Zertifikate, Secrets, Services und Jobs werden als verwaltete Teilressourcen verstanden.
4. Schritt 4 – Eingriffe begrenzen: Manuelle Änderungen an abgeleiteten Objekten werden vermieden oder als temporäre Diagnosemaßnahme klar dokumentiert.

Praxisbezug: Änderung einer Testkonfiguration über eine Custom Resource und Beobachtung der Operator-Reconciliation.

Monitoring-Architektur und Signalquellen

Monitoring verbindet Infrastruktur-, Kubernetes-, OpenStack- und Workload-Signale zu einer belastbaren Betriebsübersicht.

1. Schritt 1 – Signalquellen erfassen: Hardware-Sensoren, Betriebssysteme, Kubernetes, Operatoren, OpenStack-Dienste und externe Prüfungen werden inventarisiert.
2. Schritt 2 – Verantwortung zuordnen: Metriken werden einem Dienst, einer Fehlerdomäne und einem betrieblichen Eigentümer zugeordnet.
3. Schritt 3 – Erfassungswege prüfen: Exporter, ServiceMonitors, Scraping, Aufbewahrung und Zugriff werden auf Vollständigkeit und Ausfallsicherheit bewertet.
4. Schritt 4 – Lücken erkennen: Nicht überwachte Abhängigkeiten, unklare Grenzwerte und fehlende End-to-End-Prüfungen werden dokumentiert.

Praxisbezug: Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.

Tag 3: Sicherheit, Backup und betriebliche Kontrollen

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Bedrohungsmodell und Schutzbedarf

Das Bedrohungsmodell verbindet schützenswerte Werte, Angreiferprofile, Angriffsflächen und vorhandene Kontrollen.

1. Schritt 1 – Schutzwerte erfassen: Mandantendaten, Plattformzugänge, Schlüsselmaterial, Images, Konfigurationen und Betriebsnachweise werden klassifiziert.
2. Schritt 2 – Bedrohungen zuordnen: Externe Angriffe, Insider, Lieferkette, Fehlkonfiguration, Ausfall und Datenabfluss werden systematisch betrachtet.
3. Schritt 3 – Angriffsflächen markieren: Externe Endpunkte, Managementzugänge, APIs, Registries, Transfermedien und Wartungsschnittstellen werden bewertet.
4. Schritt 4 – Kontrollen priorisieren: Präventive, detektive und korrektive Maßnahmen werden nach Risiko und Wirksamkeit geordnet.

Praxisbezug: Erstellung eines kompakten Bedrohungsmodells mit Schutzwerten, Bedrohungen und priorisierten Kontrollen.

Härtungsbaseline für Plattformkomponenten

Eine versionierte Baseline reduziert unnötige Funktionen, beschränkt Zugriffe und definiert überprüfbare Sollwerte.

1. Schritt 1 – Komponenten erfassen: Firmware, BMC, Betriebssystem, Kubernetes, Yaook, OpenStack-Dienste und Administrationswerkzeuge werden einbezogen.
2. Schritt 2 – Sollwerte definieren: Dienste, Ports, Protokolle, Kryptografie, Dateirechte, Auditierung und Kontoschutz werden festgelegt.
3. Schritt 3 – Ausnahmen steuern: Technisch notwendige Abweichungen erhalten Begründung, Kompensationsmaßnahme, Eigentümer und Ablaufdatum.
4. Schritt 4 – Konformität messen: Automatisierte und manuelle Prüfungen liefern einen reproduzierbaren Nachweis über den aktuellen Härtungsstand.

Praxisbezug: Entwicklung einer Baseline-Prüfliste für Managementzugänge, Betriebssystem und OpenStack-APIs.

Backup-Konzept und Schutzobjekte

Das Backup-Konzept unterscheidet Plattformzustand, Konfiguration, Datenbanken, Images, Volumes, Objekte und externe Abhängigkeiten.

1. Schritt 1 – Schutzobjekte erfassen: Pro Komponente werden Dateninhalt, Konsistenzanforderung, Eigentümer und Wiederherstellungsabhängigkeiten dokumentiert.
2. Schritt 2 – RPO und RTO festlegen: Zulässiger Datenverlust und Wiederanlaufzeit werden je Service- und Datenklasse definiert.
3. Schritt 3 – Sicherungsmethode wählen: Snapshot, anwendungskoordinierte Sicherung, Datenbankbackup, Konfigurationsexport und Replikation werden passend kombiniert.
4. Schritt 4 – Aufbewahrung absichern: Rotation, getrennte Fehlerdomäne, Unveränderbarkeit, Verschlüsselung und Löschfristen werden festgelegt.

Praxisbezug: Erstellung einer Backup-Matrix mit Schutzobjekt, Methode, Intervall, RPO, RTO und Aufbewahrung.

Praxislabor

• Erstellung eines kompakten Zielbilds für einen beispielhaften KRITIS-nahen oder souveränen On-Premises-Einsatz.
• Aufbau eines Ressourcenmodells für die Bereitstellung einer virtuellen Maschine mit Netzwerk und persistentem Volume.
• Analyse einer Beispielanwendung mit Deployment, Service, ConfigMap, Secret und gestörtem Pod.
• Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.
• Erstellung eines kompakten Bedrohungsmodells mit Schutzwerten, Bedrohungen und priorisierten Kontrollen.
• Erstellung einer Backup-Matrix mit Schutzobjekt, Methode, Intervall, RPO, RTO und Aufbewahrung.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.