Kubernetes im Healthcare- und Pharma-Umfeld: DiGA, GxP und regulierte Workloads

TL;DR

• DiGA-Workloads brauchen strikte Namespace-Isolation, Encryption at Rest und nachweisbare Audit Trails fuer die BfArM-Zulassung.
• GxP-validierte Systeme erfordern Image Pinning per SHA-Digest, immutable Infrastructure und dokumentierte Change-Control-Prozesse.
• Network Policies sind kein Nice-to-have, sondern Pflicht: Gesundheitsdaten muessen auf Netzwerk-Ebene isoliert werden.
• Managed Kubernetes mit C5-Testat und ISO 27001 spart erheblich Zeit bei der Compliance-Dokumentation.
• Ein GitOps-Workflow liefert den Audit Trail quasi als Nebenprodukt.

Warum Kubernetes im regulierten Umfeld

Wer Software im Healthcare-Bereich betreibt, kennt das Spannungsfeld: Auf der einen Seite schnelle Release-Zyklen, auf der anderen Seite regulatorische Anforderungen, die jeden Deployment-Schritt dokumentiert und nachvollziehbar haben wollen. Kubernetes loest dieses Problem nicht automatisch, aber es liefert die Bausteine dafuer.

Container-Images sind versioniert und per SHA-Digest reproduzierbar. Deployments lassen sich deklarativ beschreiben und in Git verwalten. Und die API-Server-Audit-Logs zeichnen jede Aenderung am Cluster auf. Das sind genau die Eigenschaften, die Auditoren sehen wollen.

Regulatorische Anforderungen im Ueberblick

Bevor wir in die Technik einsteigen, hier die wichtigsten Regelwerke und was sie fuer die Infrastruktur bedeuten.

Die MDR betrifft Software als Medizinprodukt (SaMD). Die DiGAV regelt digitale Gesundheitsanwendungen, die auf Rezept verordnet werden. GxP kommt ins Spiel, sobald Pharma-Produktion oder klinische Studien involviert sind. In der Praxis ueberlappen sich die Anforderungen stark.

Namespace-Isolation fuer DiGA-Workloads

Der erste Schritt bei jeder regulierten Workload ist die Isolation. Ein eigener Namespace mit passenden Labels und einer Default-Deny NetworkPolicy ist das Minimum.

apiVersion: v1
kind: Namespace
metadata:
  name: diga-production
  labels:
    compliance: diga
    data-classification: health-data
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: diga-production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Dieses Setup blockiert saemtlichen Traffic in und aus dem Namespace. Anschliessend oeffnet man gezielt nur die Kommunikationspfade, die tatsaechlich benoetigt werden. Das ist das Gegenteil von dem, was viele Teams gewohnt sind, aber bei Gesundheitsdaten fuehrt kein Weg daran vorbei.

Fuer den Ingress-Traffic und die Kommunikation mit externen APIs wie der GKV-Schnittstelle fuegt man dann spezifische Regeln hinzu:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-and-gkv
  namespace: diga-production
spec:
  podSelector:
    matchLabels:
      app: diga-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-controller
      ports:
        - protocol: TCP
          port: 8443
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: diga-production
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - protocol: TCP
          port: 443

Wichtig: Die Egress-Regel auf Port 443 ist bewusst breit. In der Praxis sollte man hier die konkreten IP-Ranges der GKV-SV-API und der eigenen Backend-Services eintragen. Der Punkt ist, dass man mit Network Policies eine nachweisbare Netzwerk-Segmentierung hat, die Auditoren verstehen.

GxP-validierte Deployments: Image Pinning und Change Control

Fuer GxP-validierte Systeme gilt: Kein automatisches Update, keine unkontrollierte Aenderung. Jedes Deployment muss reproduzierbar sein und einem dokumentierten Change-Control-Prozess folgen.

In der Praxis bedeutet das Image Pinning per SHA-Digest statt Tag:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: clinical-trial-mgmt
  namespace: gxp-validated
  labels:
    gxp-status: validated
    validation-protocol: VP-2026-001
  annotations:
    gxp.internal/validated-by: qa-team
    gxp.internal/change-control: CC-2026-0042
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ctms
  template:
    metadata:
      labels:
        app: ctms
    spec:
      automountServiceAccountToken: false
      containers:
        - name: ctms-app
          image: registry.internal/ctms@sha256:a1b2c3d4e5f6...
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              cpu: "1"
              memory: "2Gi"
            limits:
              cpu: "2"
              memory: "4Gi"
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

Drei Dinge fallen auf:

1. Das Image wird per Digest referenziert. Selbst wenn jemand den Tag ueberschreibt, aendert sich der laufende Container nicht.
2. automountServiceAccountToken: false verhindert, dass der Container unnoetig Zugriff auf die Kubernetes-API bekommt.
3. readOnlyRootFilesystem stellt sicher, dass zur Laufzeit nichts im Container veraendert wird.

Der Change-Control-Prozess selbst liegt ausserhalb von Kubernetes. Aber die Annotations im Manifest machen die Zuordnung zum Change-Control-Ticket nachvollziehbar. Zusammen mit einem GitOps-Workflow (ArgoCD oder Flux) entsteht ein lueckenloser Audit Trail von der Aenderungsanfrage bis zum laufenden Pod.

Audit-Logging fuer FDA 21 CFR Part 11

Wer den US-Markt bedient oder klinische Studien faehrt, braucht tamper-evident Audit Trails nach 21 CFR Part 11. Kubernetes bringt mit der API-Server Audit Policy bereits ein solides Fundament mit.

# Audit Policy als Datei auf den Control-Plane-Nodes ablegen
# und in der kube-apiserver-Konfiguration referenzieren:
# --audit-policy-file=/etc/kubernetes/audit-policy.yaml
# --audit-log-path=/var/log/kubernetes/audit.log
# --audit-log-maxage=365
# --audit-log-maxbackup=10
# --audit-log-maxsize=100

Die Policy selbst definiert, welche Events auf welchem Level geloggt werden. Fuer regulierte Namespaces empfiehlt sich RequestResponse, damit sowohl die Anfrage als auch die Antwort erfasst werden:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
    namespaces: ["gxp-validated", "diga-production"]
  - level: RequestResponse
    resources:
      - group: "apps"
        resources: ["deployments", "statefulsets"]
    verbs: ["create", "update", "patch", "delete"]
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
  - level: Metadata
    resources:
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"

Diese Logs muessen anschliessend in ein SIEM-System oder einen Write-Once-Storage fliessen. Lokal auf dem Node reicht nicht fuer Compliance. Tools wie Fluentd oder Vector koennen die Logs in Echtzeit an S3-kompatiblen Storage mit Object Lock weiterleiten.

Vergleich: Managed vs. Self-Managed fuer regulierte Workloads

Fuer die meisten Healthcare-Organisationen ist Managed Kubernetes die bessere Wahl, weil man die Zertifizierungen des Providers nutzen kann. Allerdings muss man die Shared-Responsibility-Matrix genau verstehen: Der Provider sichert die Control Plane, aber fuer Network Policies, RBAC und die Anwendungssicherheit bleibt man selbst verantwortlich.

Best Practices fuer Healthcare-Kubernetes

Immutable Infrastructure: Container zur Laufzeit nicht veraendern. Kein kubectl exec in Produktions-Pods. Aenderungen nur ueber neue Deployments nach Validierung.

GitOps als Audit Trail: Jede Infrastruktur-Aenderung laeuft ueber einen Pull Request. Das Review-Verfahren in Git bildet den Change-Control-Prozess ab. ArgoCD synchronisiert den gewuenschten Zustand automatisch mit dem Cluster. Mehr dazu unter GitOps mit ArgoCD.

Encryption at Rest und in Transit: Secrets mit einem KMS-Provider verschluesseln (nicht Base64, das ist keine Verschluesselung). Service Mesh fuer mTLS zwischen Services einsetzen. Ein Vergleich der Optionen findet sich unter Istio vs. Linkerd.

RBAC nach dem Least-Privilege-Prinzip: Entwickler bekommen Read-Only-Zugriff auf Logs. Deployments laufen ausschliesslich ueber die CI/CD-Pipeline. Auditoren bekommen einen dedizierten ClusterRole mit reinen Lese-Rechten. Details zu RBAC-Konzepten gibt es unter Kubernetes RBAC Enterprise.

Disaster Recovery testen: RTO und RPO definieren und regelmaessig testen. Fuer Patientendaten ist ein RPO von wenigen Minuten oft Pflicht. Backup-Strategien finden sich unter Kubernetes Backup.

DSGVO und Gesundheitsdaten

Gesundheitsdaten fallen unter Art. 9 DSGVO (besondere Kategorien personenbezogener Daten). Das bedeutet: Verarbeitungsverzeichnis, Datenschutz-Folgenabschaetzung und technisch-organisatorische Massnahmen sind Pflicht. Auf Kubernetes-Ebene gehoert dazu die Namespace-Isolation, Encryption at Rest, Zugriffskontrolle per RBAC und vollstaendiges Audit-Logging.

Wer einen Managed-Provider nutzt, braucht einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Mehr zu DSGVO-konformem Kubernetes-Betrieb steht unter Cloud DSGVO Kubernetes Compliance.

Continuous Compliance mit Policy Engines

Manuelle Compliance-Pruefungen skalieren nicht. Bei jedem Deployment manuell zu pruefen, ob die Security Context richtig gesetzt ist, ist fehleranfaellig und langsam. Policy Engines wie Kyverno oder OPA Gatekeeper automatisieren das.

Ein Beispiel: Eine Kyverno-Policy, die sicherstellt, dass in regulierten Namespaces keine Container mit Root-Rechten laufen:

# Kyverno installieren
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

# Policy anwenden, die Root-Container in gxp-validated blockiert
kubectl apply -f - <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-non-root
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-non-root
      match:
        resources:
          kinds: ["Pod"]
          namespaces: ["gxp-validated", "diga-production"]
      validate:
        message: "Container muessen als non-root laufen."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true
EOF

Wenn jetzt jemand versucht, einen Container ohne runAsNonRoot: true in den Namespace gxp-validated zu deployen, wird das Deployment abgelehnt. Das ist Compliance by Default, nicht Compliance by Hope.

Fazit

Kubernetes im Healthcare- und Pharma-Umfeld ist kein Selbstlaeufer, aber die Plattform bringt genau die Eigenschaften mit, die regulierte Umgebungen brauchen: deklarative Konfiguration, Versionierung, Audit-Faehigkeit und Reproduzierbarkeit. Der Aufwand liegt nicht in der Technik selbst, sondern in der sauberen Dokumentation und der Disziplin, die Prozesse auch einzuhalten.

Der wichtigste Rat: Fangt frueher mit der Compliance-Arbeit an, nicht erst kurz vor der Zulassung. Die technischen Bausteine in Kubernetes sind vorhanden. Man muss sie nur von Anfang an richtig zusammensetzen.

Wenn Sie Unterstuetzung beim Aufbau einer regulierten Kubernetes-Plattform brauchen, melden Sie sich gerne unter /kontakt.