Container fuer Versicherungen: Kubernetes in der Versicherungswirtschaft

TL;DR

• Versicherungen betreiben oft monolithische Host-Systeme, die Release-Zyklen von Monaten erzwingen -- Kubernetes reduziert das auf Tage.
• BaFin-Anforderungen (VAIT, Solvency II) lassen sich mit RBAC, Network Policies und Audit Logging direkt auf Kubernetes-Ressourcen abbilden.
• Multi-Tenancy pro Sparte (Leben, Sach, KFZ) isoliert Daten und Workloads sauber ueber Namespaces und Resource Quotas.
• Ein Strangler-Fig-Ansatz migriert Legacy-Bestandsfuehrung schrittweise, ohne den laufenden Betrieb zu gefaehrden.
• Die hoehere Ressourcenauslastung und schnelleren Release-Zyklen rechnen sich ab dem zweiten Jahr messbar.

Ausgangslage: Warum Versicherungen unter Modernisierungsdruck stehen

Die IT-Landschaft vieler Versicherungsunternehmen ist historisch gewachsen. Kernprozesse wie Bestandsfuehrung, Schadensmanagement und Tarifierung laufen auf Mainframe- oder Host-Systemen, die vor 15-25 Jahren implementiert wurden. Neue Anforderungen -- digitale Kundenportale, Echtzeit-Tarifierung, automatisierte Schadensregulierung -- lassen sich auf diesen Systemen nur mit erheblichem Aufwand umsetzen.

Das bedeutet nicht, dass die Host-Systeme sofort abgeloest werden muessen. Aber fuer neue Services und eine schrittweise Migration bietet Kubernetes die passende Plattform.

Referenzarchitektur fuer Versicherungen

Die folgende Architektur hat sich fuer mittelgrosse Versicherungsunternehmen (500-5.000 Mitarbeitende) bewaehrt. Sie laesst sich sowohl on-premise als auch in einer Private Cloud betreiben.

Zentrale Komponenten:

• Control Plane: 3 Master-Nodes (HA), etcd mit Encryption at Rest
• Worker Pools: Getrennt nach Sparten und Workload-Typ (Batch, Online, Analytics)
• CNI: Calico fuer Network Policies und Mikrosegmentierung
• CSI: NetApp Trident oder Rook-Ceph fuer persistenten Storage
• Ingress: NGINX Ingress Controller mit mTLS via cert-manager
• Service Mesh: Istio fuer verschluesselte Service-to-Service-Kommunikation
• Monitoring: Prometheus + Grafana mit spartenspezifischen Dashboards
• CI/CD: Argo CD fuer GitOps-basierte Deployments

Multi-Tenancy nach Sparten

Jede Versicherungssparte erhaelt einen eigenen Namespace-Bereich mit dedizierten Resource Quotas. Damit wird sichergestellt, dass ein Lastpeak in der KFZ-Schadensregulierung nicht die Bestandsfuehrung der Lebensversicherung beeintraechtigt. Mehr zur Umsetzung unter Multi-Tenancy fuer Kubernetes in regulierten Umgebungen.

apiVersion: v1
kind: Namespace
metadata:
  name: sparte-leben
  labels:
    sparte: leben
    compliance: vait
    data-classification: vertraulich
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: leben-quota
  namespace: sparte-leben
spec:
  hard:
    requests.cpu: "16"
    requests.memory: "32Gi"
    limits.cpu: "32"
    limits.memory: "64Gi"
    persistentvolumeclaims: "20"
    pods: "100"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: leben-defaults
  namespace: sparte-leben
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    type: Container

Network Policy: Sparten-Isolation

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-sparte
  namespace: sparte-leben
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          sparte: leben
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          sparte: leben
  - to:
    - namespaceSelector:
        matchLabels:
          shared-service: "true"
    ports:
    - protocol: TCP
      port: 443

Diese Policy stellt sicher, dass Pods in der Sparte Leben nur mit anderen Pods derselben Sparte oder mit explizit freigegebenen Shared Services kommunizieren koennen. Das Versicherungsgeheimnis wird damit auf Netzwerkebene durchgesetzt.

BaFin-Compliance: VAIT und Solvency II auf Kubernetes

Die BaFin stellt ueber die VAIT (Versicherungsaufsichtliche Anforderungen an die IT) klare Vorgaben fuer den IT-Betrieb. Diese lassen sich direkt auf Kubernetes-Konzepte mappen. Detaillierte Informationen zur BaFin-konformen Kubernetes-Architektur finden Sie unter Kubernetes fuer Finanzdienstleister: BaFin-Compliance.

RBAC fuer das Berechtigungsmanagement

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: schaden-developer
  namespace: sparte-sach
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update"]
- apiGroups: [""]
  resources: ["pods", "pods/log", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: schaden-team-binding
  namespace: sparte-sach
subjects:
- kind: Group
  name: "team-schadenmanagement"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: schaden-developer
  apiGroup: rbac.authorization.k8s.io

Audit Logging fuer Pruefungssicherheit

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
  namespaces: ["sparte-leben", "sparte-sach", "sparte-kfz"]
- level: Metadata
  resources:
  - group: "apps"
    resources: ["deployments"]
- level: Request
  users: ["system:serviceaccount:*"]
  verbs: ["create", "delete", "patch"]

Diese Audit Policy protokolliert alle sicherheitsrelevanten Zugriffe mit vollem Request/Response-Body fuer Secrets und ConfigMaps. Bei einer BaFin-Pruefung koennen Sie damit lueckenlos nachweisen, wer wann auf welche Daten zugegriffen hat.

Legacy-Migration: Vom Host-System zum Container

Die Migration von Kernsystemen wie der Bestandsfuehrung ist ein mehrjaehriges Projekt. Der bewaehrte Ansatz ist das Strangler-Fig-Pattern: Neue Funktionalitaet wird in Containern gebaut, waehrend das Legacy-System schrittweise zurueckgebaut wird. Fuer bewaehtere Strategien zur Migration siehe Legacy-Applikationen nach Kubernetes migrieren.

Phase 1 -- API-Gateway vor das Host-System:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: versicherung-api-gateway
  namespace: integration
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
    spec:
      containers:
      - name: gateway
        image: registry.internal/versicherung/api-gateway:1.8.0
        ports:
        - containerPort: 8080
        env:
        - name: LEGACY_HOST_URL
          value: "https://bestand.legacy.internal:8443"
        - name: NEW_TARIF_URL
          value: "http://tarif-service.sparte-sach.svc.cluster.local:8080"
        - name: ROUTING_MODE
          value: "feature-flag"
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Das API-Gateway routet Anfragen entweder an das Legacy-System oder an den neuen containerisierten Service -- gesteuert ueber Feature Flags. So koennen einzelne Funktionen schrittweise umgezogen werden, ohne den Betrieb zu unterbrechen.

Phase 2 -- Neue Tarifierung als Microservice:

Der Tarifierungsservice ist ein guter Kandidat fuer die erste Migration: Er ist zustandslos, hat klar definierte Ein- und Ausgaben und profitiert stark von horizontaler Skalierung -- etwa bei saisonalen Peaks im KFZ-Bereich.

Phase 3 -- Schadensmanagement entkoppeln:

Das Schadensmanagement wird Schritt fuer Schritt migriert. Dokumenten-Upload, Bildanalyse (z.B. KFZ-Gutachten) und Statusverfolgung werden als einzelne Services containerisiert.

Datenschutz: Das Versicherungsgeheimnis

Versicherungsdaten unterliegen neben der DSGVO dem Versicherungsgeheimnis. Das bedeutet:

• Encryption at Rest: etcd-Verschluesselung ist Pflicht, nicht optional
• Encryption in Transit: mTLS zwischen allen Services via Service Mesh
• Datenlokalitaet: Cluster in EU-Rechenzentren, keine Datenverarbeitung ausserhalb
• Zugriffskontrolle: Mandantentrennung auf Namespace-Ebene, keine Cross-Sparten-Zugriffe
• Datenloesch-Konzept: Automated Retention Policies fuer personenbezogene Daten

Fuer weitergehende Compliance-Anforderungen siehe DSGVO-konforme Kubernetes-Infrastruktur.

Praxisbeispiel: KFZ-Schadensregulierung

Ein konkreter Anwendungsfall, der den Mehrwert von Kubernetes illustriert:

1. Schadensmeldung: Kunde laedt Fotos ueber das Kundenportal hoch (containerisiertes Frontend)
2. Bildanalyse: Ein ML-Modell im Cluster bewertet den Schaden vorab (GPU-Worker-Pool)
3. Tarifierung: Der Schadenwert wird automatisch kalkuliert (Tarif-Microservice)
4. Regulierung: Bei Kleinschaeden erfolgt die Regulierung vollautomatisch (Business-Rules-Engine)
5. Benachrichtigung: Kunde erhaelt Status-Updates in Echtzeit (Event-Driven mit Kafka)

Dieser Prozess laeuft komplett auf Kubernetes. Bei einem Hagelsturm -- wenn tausende Schadensmeldungen gleichzeitig eingehen -- skaliert die Plattform automatisch hoch. Auf einem Legacy-System waere das ein mehrstuendiger Ausfall.

Kostenvergleich

Die initialen Migrationskosten (Schulung, Beratung, Infrastruktur) liegen typischerweise bei 150.000 - 400.000 EUR. Der Return on Investment wird in der Regel nach 18-24 Monaten erreicht.

Typische Stolpersteine

Regulatorik unterschaetzt: VAIT-Anforderungen muessen von Anfang an in die Architektur einfliessen, nicht als Nachgedanke. Eine nachtraegliche Haertung kostet ein Vielfaches.

Zu viele Microservices auf einmal: Beginnen Sie mit 2-3 klar abgegrenzten Services, nicht mit der gesamten Bestandsfuehrung.

Vendor Lock-in bei Managed Kubernetes: Achten Sie auf portierbare Konfiguration. Helm Charts und Kustomize statt proprietaerer Abstraktion.

Fehlende Observability: Ohne Monitoring, Logging und Tracing ist ein containerisiertes System schwerer zu debuggen als ein Monolith. Investieren Sie frueh in die Observability-Infrastruktur.

Fazit

Kubernetes ist fuer die Versicherungswirtschaft kein Technologie-Experiment mehr, sondern eine strategische Plattformentscheidung. Die Kombination aus Multi-Tenancy, deklarativer Konfiguration und automatisierter Skalierung passt zu den Anforderungen einer Branche, die gleichzeitig reguliert und unter Innovationsdruck steht. Der Einstieg gelingt am besten ueber ein klar begrenztes Pilotprojekt -- etwa die Tarifierung oder ein Kundenportal -- mit dem Ziel, innerhalb von 90 Tagen den ersten produktiven Workload zu betreiben.

Wenn Sie Unterstuetzung bei der Planung oder Umsetzung Ihrer Container-Strategie brauchen -- von der BaFin-konformen Architektur bis zum Hands-on-Workshop -- sprechen Sie uns an unter /kontakt.