TL;DR

• SEVESO-III-Richtlinie stellt spezifische Anforderungen an IT-Systeme in Chemiebetrieben -- Kubernetes muss diese von Anfang an abbilden
• OT/IT-Konvergenz erfordert sichere Anbindung von SCADA- und PLC-Systemen an Container-Plattformen
• Safety Integrity Level (SIL) nach IEC 61511 bestimmt die Architektur-Anforderungen fuer Kubernetes-Workloads
• Prozessindustrie braucht deterministische Latenzen und garantierte Verfuegbarkeit -- nicht Standard-Cloud-Patterns
• Ein Managed Service mit Prozessindustrie-Erfahrung reduziert Risiken und entlastet interne Teams

Kubernetes fuer Chemieindustrie: SEVESO-Compliance fuer Prozesssteuerung

Chemiebetriebe, die unter die SEVESO-III-Richtlinie fallen, stehen vor einer besonderen Herausforderung: Die Digitalisierung der Prozesssteuerung ist laengst keine Option mehr, aber die regulatorischen Anforderungen an Safety und Security sind in kaum einer anderen Branche so hoch. Kubernetes kann hier die Plattform fuer moderne Prozess-IT liefern -- wenn man die branchenspezifischen Anforderungen kennt.

Dieser Artikel zeigt, wie Chemiemittelstaendler mit 200 bis 2.000 Mitarbeitern Kubernetes SEVESO-konform betreiben, OT und IT sicher verbinden und dabei nicht zum Cloud-Native-Spezialisten werden muessen.

SEVESO-III: Was die Richtlinie fuer IT-Systeme bedeutet

Die SEVESO-III-Richtlinie (Richtlinie 2012/18/EU) regelt die Beherrschung von Gefahren bei schweren Unfaellen mit gefaehrlichen Stoffen. In Deutschland umgesetzt durch die Stoerfallverordnung (12. BImSchV), betrifft sie Betriebe, die bestimmte Mengen gefaehrlicher Stoffe handhaben.

Relevanz fuer Kubernetes

IT-Systeme fallen unter SEVESO, sobald sie an sicherheitsrelevanten Funktionen beteiligt sind. Das betrifft:

Betriebsbereiche nach Stoerfallverordnung

Safety Integrity Level und Kubernetes-Architektur

Die IEC 61511 definiert Safety Integrity Levels (SIL) fuer die Prozessindustrie. Wenn Kubernetes-Workloads an sicherheitsrelevanten Funktionen beteiligt sind, bestimmt das SIL die Architektur.

SIL-Anforderungen und Kubernetes-Mapping

Wichtig: SIL 4 erfordert spezielle Hardware und redundante Systeme. Kubernetes-basierte Workloads sind hier nur als Monitoring- oder Reporting-Schicht sinnvoll, nicht als Teil der Safety-Funktion selbst.

Beispiel: SIL-2-konforme Deployment-Konfiguration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: process-monitor
  namespace: seveso-safety
  labels:
    safety-level: "sil-2"
    seveso-relevant: "true"
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: process-monitor
  template:
    metadata:
      labels:
        app: process-monitor
        safety-level: "sil-2"
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: process-monitor
            topologyKey: topology.kubernetes.io/zone
      priorityClassName: safety-critical
      containers:
      - name: monitor
        image: registry.internal/process-monitor:v3.2.1
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
          limits:
            cpu: "2"
            memory: "4Gi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3
          failureThreshold: 2
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 2

Der entscheidende Punkt: maxUnavailable: 0 stellt sicher, dass waehrend Rolling Updates immer alle Replicas verfuegbar bleiben. Die Pod-Anti-Affinity verteilt die Pods ueber verschiedene Zonen. Requests und Limits sind identisch gesetzt, um Guaranteed QoS zu erhalten -- das verhindert, dass der Kubelet den Pod bei Ressourcenknappheit evicted.

OT/IT-Konvergenz: SCADA und PLC an Kubernetes anbinden

Die groesste technische Herausforderung in der Chemieindustrie ist die Verbindung von Operational Technology (OT) mit der IT-Welt. SCADA-Systeme, SPS/PLC-Steuerungen und Prozessleitsysteme (DCS) sprechen andere Protokolle und haben andere Verfuegbarkeitsanforderungen als Web-Applikationen.

Architektur: Sichere OT/IT-Integration

Die Integration erfolgt ueber eine DMZ zwischen OT- und IT-Netzwerk. Kubernetes-Workloads laufen in der IT-Zone und kommunizieren ueber definierte Gateways mit der OT-Ebene.

OPC UA Gateway auf Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-gateway
  namespace: ot-integration
  labels:
    zone: dmz
    data-flow: ot-to-it
spec:
  replicas: 2
  selector:
    matchLabels:
      app: opcua-gateway
  template:
    metadata:
      labels:
        app: opcua-gateway
        zone: dmz
    spec:
      nodeSelector:
        network-zone: dmz
      containers:
      - name: gateway
        image: registry.internal/opcua-gw:v2.1.0
        ports:
        - containerPort: 4840
          name: opcua
        - containerPort: 8883
          name: mqtt-tls
        env:
        - name: OPC_UA_SECURITY_MODE
          value: "SignAndEncrypt"
        - name: OPC_UA_SECURITY_POLICY
          value: "Aes256_Sha256_RsaPss"
        - name: DATA_DIODE_MODE
          value: "read-only"
        volumeMounts:
        - name: opcua-certs
          mountPath: /etc/opcua/certs
          readOnly: true
      volumes:
      - name: opcua-certs
        secret:
          secretName: opcua-gateway-certs

Das DATA_DIODE_MODE: read-only ist entscheidend: Der Gateway liest nur Daten aus der OT-Ebene, schreibt aber nie zurueck. Das entspricht dem Purdue-Modell fuer industrielle Netzwerksicherheit.

Network Policy fuer OT-DMZ

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ot-dmz-policy
  namespace: ot-integration
spec:
  podSelector:
    matchLabels:
      zone: dmz
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.100.0.0/24  # OT-Netzwerk
    ports:
    - protocol: TCP
      port: 4840  # OPC UA
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          tier: data-platform
    ports:
    - protocol: TCP
      port: 8883  # MQTT TLS
  - to:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9090

Diese Policy erlaubt dem OPC-UA-Gateway nur eingehende Verbindungen aus dem OT-Netzwerk und ausgehende Verbindungen zur Datenplattform und zum Monitoring. Alles andere wird blockiert.

Prozessdaten-Pipeline: Vom Sensor bis zum Dashboard

In der Chemieindustrie fallen grosse Mengen zeitkritischer Prozessdaten an. Temperaturen, Druecke, Fuellstaende und Durchflussraten muessen in Echtzeit erfasst, verarbeitet und visualisiert werden.

Typische Pipeline-Architektur

apiVersion: apps/v1
kind: Deployment
metadata:
  name: process-data-collector
  namespace: data-pipeline
spec:
  replicas: 3
  selector:
    matchLabels:
      app: data-collector
  template:
    metadata:
      labels:
        app: data-collector
    spec:
      containers:
      - name: collector
        image: registry.internal/process-collector:v1.8.0
        env:
        - name: MQTT_BROKER
          value: "mqtt-broker.data-pipeline.svc:8883"
        - name: BUFFER_SIZE_MB
          value: "512"
        - name: FLUSH_INTERVAL_MS
          value: "1000"
        - name: STORE_AND_FORWARD
          value: "true"
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "2Gi"

Die STORE_AND_FORWARD-Funktion ist fuer die Prozessindustrie wichtig: Bei Netzwerkunterbrechungen werden Daten lokal gepuffert und spaeter nachgeliefert. So gehen keine Messwerte verloren.

Alarm-Management auf Kubernetes

SEVESO-Betriebe muessen ein nachvollziehbares Alarm-Management betreiben. Jeder sicherheitsrelevante Alarm muss protokolliert, priorisiert und bearbeitet werden. Die IEC 62682 definiert die Anforderungen.

Alarm-Priorisierung

Pod Disruption Budget fuer Safety-Workloads

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: alarm-handler-pdb
  namespace: seveso-safety
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: alarm-handler
      safety-level: "sil-2"

Dieses PDB stellt sicher, dass immer mindestens zwei Alarm-Handler-Pods laufen, selbst waehrend Node-Wartung oder Cluster-Updates. In Kombination mit Anti-Affinity-Regeln ergibt das eine robuste Alarm-Verarbeitung.

Sicherheitsbericht und Dokumentation

SEVESO-Betriebe der oberen Klasse muessen einen Sicherheitsbericht erstellen und regelmaessig aktualisieren. IT-Systeme, die an sicherheitsrelevanten Funktionen beteiligt sind, muessen darin dokumentiert sein.

GitOps als Dokumentationsgrundlage

Ein GitOps-Workflow mit ArgoCD oder Flux liefert den Nachweis der IT-Konfiguration automatisch:

• Jede Aenderung an der Kubernetes-Konfiguration ist in Git nachvollziehbar
• Wer hat wann welche Aenderung vorgenommen?
• Rollback auf jeden frueheren Zustand moeglich
• Automatische Drift-Detection erkennt manuelle Aenderungen

Das vereinfacht die Vorbereitung auf behoerdliche Inspektionen erheblich. Mehr dazu unter GitOps mit ArgoCD.

Audit-Logging fuer SEVESO-Nachweise

apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  name: seveso-audit-policy
rules:
- level: RequestResponse
  namespaces: ["seveso-safety", "ot-integration"]
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: ""
    resources: ["pods", "configmaps", "secrets"]
  - group: "apps"
    resources: ["deployments", "statefulsets"]
- level: Metadata
  namespaces: ["seveso-safety"]
  verbs: ["get", "list", "watch"]

Warum Kubernetes in der Chemie Spezialwissen erfordert

Die Chemieindustrie unterscheidet sich grundlegend von typischen Kubernetes-Use-Cases:

Herausforderungen gegenueber Standard-IT

Typische Fehler bei Self-Managed Kubernetes in der Chemie

1. Standard-Cloud-Patterns uebernommen: Auto-Scaling, das Pods bei Last startet und stoppt, funktioniert nicht fuer sicherheitskritische Workloads. Die Pods muessen immer laufen.

2. OT-Netzwerk nicht isoliert: Ohne strikte Network Policies und DMZ-Architektur riskiert man laterale Bewegung zwischen IT und OT.

3. Kein Change Management: In der Prozessindustrie muss jede Aenderung an sicherheitsrelevanten Systemen einem MOC-Prozess (Management of Change) folgen.

4. Fehlende Validierung: Updates an Container-Images muessen wie Software-Aenderungen an Safety-Systemen validiert werden.

5. Kein 24/7-Betrieb: Chemische Anlagen laufen durchgehend. Ein Kubernetes-Cluster, der nur waehrend der Buerozeiten betreut wird, ist ein Risiko.

Managed Service: Prozessindustrie-Expertise einkaufen

Fuer Chemiemittelstaendler mit 200 bis 2.000 Mitarbeitern ist der Aufbau eines internen Kubernetes-Teams mit Prozessindustrie-Erfahrung unrealistisch. Die Kombination aus Container-Expertise und Branchenwissen ist auf dem Arbeitsmarkt extrem selten.

Kosten: Intern vs. Managed Service

Mehr zum Kostenvergleich unter Kubernetes Kosten: Intern vs. Extern.

Was ein Managed Service fuer die Chemieindustrie leisten muss

Ein generischer Managed-Kubernetes-Anbieter reicht fuer SEVESO-Betriebe nicht aus. Der Provider muss:

• OT/IT-Konvergenz verstehen: Erfahrung mit SCADA-Integration, OPC UA und dem Purdue-Modell
• Safety-Anforderungen kennen: IEC 61511, SIL-Bewertung, LOPA-Analysen
• Regulatorisch firm sein: SEVESO-III, Stoerfallverordnung, ATEX-Richtlinie
• 24/7-Betrieb gewaehrleisten: Chemische Anlagen laufen durchgehend, die Kubernetes-Plattform muss das auch
• Change Management unterstuetzen: MOC-Prozesse in den Deployment-Workflow integrieren
• Audit-Support bieten: Unterstuetzung bei behoerdlichen Inspektionen

Ein Ueberblick ueber Managed-Kubernetes-Optionen findet sich unter Managed Kubernetes Plattformen im Vergleich.

Praxisbeispiel: Chemiemittelstaendler mit 400 Mitarbeitern

Ein typisches Szenario fuer einen SEVESO-Betrieb im Mittelstand:

Ausgangslage

• Spezialchemie-Hersteller, SEVESO obere Klasse
• 3 Produktionslinien, 24/7 Betrieb
• Bestehendes SCADA-System (Siemens PCS 7)
• ERP-System (SAP S/4HANA)
• Wunsch: Digitalisierung der Prozessueberwachung, vorausschauende Wartung

Loesung mit Managed Kubernetes

Ergebnisse nach 12 Monaten

Checkliste: Kubernetes-Einfuehrung in SEVESO-Betrieben

Vor dem Start eines Kubernetes-Projekts in der Chemieindustrie sollten diese Punkte geklaert sein:

• Welche Workloads sind SEVESO-relevant und welches SIL wird benoetigt?
• Ist eine OT/IT-Trennung nach Purdue-Modell vorhanden oder muss sie aufgebaut werden?
• Welche Protokolle muessen unterstuetzt werden (OPC UA, Modbus, MQTT)?
• Gibt es einen MOC-Prozess fuer IT-Aenderungen?
• Ist 24/7-Betrieb fuer den Kubernetes-Cluster sichergestellt?
• Sind die Anforderungen fuer den Sicherheitsbericht bekannt?
• Gibt es Erfahrung mit IEC 61511 und SIL-Bewertung?

Wer sich unsicher ist, kann mit einem Architektur-Review starten.

Fazit

Kubernetes fuer die Chemieindustrie ist technisch machbar, erfordert aber ein Verstaendnis der branchenspezifischen Anforderungen. SEVESO-Compliance, SIL-Bewertung und OT/IT-Konvergenz sind keine Themen, die man nebenbei loest. Die technischen Bausteine von Kubernetes -- Pod-Anti-Affinity, PDBs, Network Policies, Audit Logging -- liefern die Grundlage. Aber die korrekte Anwendung im Kontext der Prozessindustrie erfordert Erfahrung.

Fuer Chemiemittelstaendler ist ein Managed Service mit Branchenerfahrung der pragmatischste Weg. Die Kosten liegen deutlich unter dem Aufbau eines internen Teams, und die Expertise ist vom ersten Tag an verfuegbar. Mehr zum Thema Betrieb auslagern unter Kubernetes Betrieb auslagern.

Verwandte Artikel

• Kubernetes Compliance: DSGVO und BSI in Deutschland
• Kubernetes 24/7-Betrieb fuer den Mittelstand
• Kubernetes ohne DevOps-Team im Mittelstand
• Kubernetes MES-Integration
• Kubernetes Security Hardening: Best Practices

Sie betreiben einen SEVESO-Betrieb und wollen Kubernetes fuer Prozessueberwachung oder Datenplattformen einsetzen? Sprechen Sie uns an unter /kontakt -- wir bringen Kubernetes-Expertise und Prozessindustrie-Erfahrung zusammen.