Drohnen-Compliance auf Kubernetes: EASA und LBA automatisieren

TL;DR

• LBA- und EASA-Regeln lassen sich als Policy-as-Code in OPA (Open Policy Agent) oder Kyverno abbilden und bei jeder Flugplan-Einreichung automatisch pruefen.
• Ein Geo-Fencing-Service vergleicht Echtzeit-Positionen gegen No-Fly-Zones aus einer PostGIS-Datenbank und loest bei Verstoessen Alerts aus.
• Alle Flugdaten werden revisionssicher in einem S3-kompatiblen Object Store (MinIO) gespeichert -- mit definierten Retention-Policies und Audit-Zugriff.
• NetworkPolicies und RBAC trennen Compliance-Services strikt von operativen Workloads, was Auditoren nachvollziehbare Zugriffskontrollen demonstriert.
• Der EU AI Act betrifft Drohnen mit autonomer Navigation direkt: Modellversionierung, Logging und menschliche Aufsicht muessen im Cluster abgebildet sein.

Hintergrund: Regulatorisches Umfeld fuer Drohnenoperationen

Seit 2021 gelten in der EU einheitliche Regeln fuer unbemannte Luftfahrzeuge, umgesetzt durch die EASA (European Union Aviation Safety Agency). Das LBA (Luftfahrt-Bundesamt) ist die nationale Aufsichtsbehoerde und setzt die EASA-Verordnungen in der Praxis durch.

Die drei EASA-Kategorien bestimmen den Compliance-Aufwand:

Die meisten kommerziellen Anwendungen (Inspektion, Vermessung, Logistik) fallen in die Kategorie "Specific". Hier ist der Compliance-Aufwand signifikant: Jeder Flug braucht einen validierten Flugplan, geprueften Piloten, dokumentierte Risikobewertung und lueckenlose Protokollierung.

Genau diesen Aufwand kann Kubernetes automatisieren.

Architektur: Compliance als Microservice-Plattform

Die Grundidee: Jede regulatorische Anforderung wird als eigenstaendiger Microservice implementiert, der ueber definierte APIs angesprochen wird. Kubernetes orchestriert diese Services, skaliert sie bei Bedarf und stellt Hochverfuegbarkeit sicher.

Kernservices im Cluster:

• Geo-Fencing-Service: Empfaengt Positionsdaten (GPS-Koordinaten, Hoehe) per MQTT oder gRPC. Prueft gegen PostGIS-Datenbank mit Flugverbotszonen, temporaeren Luftraumbeschraenkungen und genehmigten Korridoren. Gibt Pass/Fail zurueck und loggt Verstoesse.
• Flugplan-Validator: Nimmt Flugplaene als JSON entgegen, prueft gegen Regelwerk (max. Flughoehe, Abstand zu Flughaefen, Tageszeit, Wetterlimits). Nutzt OPA/Rego fuer die Regel-Evaluation.
• Pilot-ID-Service: Validiert Pilotenlizenzen, Betreiber-Registrierungen und Versicherungsnachweise gegen eine zentrale Datenbank.
• Audit-Logger: Schreibt alle Compliance-Events revisionssicher in MinIO. Stellt eine Query-API fuer Auditoren bereit.
• Alert-Manager: Routet Compliance-Verstoesse an Operatoren (Slack, E-Mail) und bei schwerwiegenden Verstoessen an den Incident-Management-Prozess.

Praxis: Geo-Fencing-Service mit PostGIS

Das Herzstuck der Compliance-Plattform ist der Geo-Fencing-Service. Er nutzt PostGIS fuer raeumliche Abfragen -- zum Beispiel "Liegt der aktuelle GPS-Punkt innerhalb einer Flugverbotszone?"

Das Deployment fuer die PostGIS-Datenbank und den Geo-Fencing-Service:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: geofencing-db
  namespace: drone-compliance
spec:
  serviceName: geofencing-db
  replicas: 1
  selector:
    matchLabels:
      app: geofencing-db
  template:
    metadata:
      labels:
        app: geofencing-db
    spec:
      containers:
      - name: postgis
        image: postgis/postgis:15-3.4
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_DB
          value: "geofencing"
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: geofencing-db-credentials
              key: username
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: geofencing-db-credentials
              key: password
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "1"
            memory: "2Gi"
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: local-path
      resources:
        requests:
          storage: 10Gi
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: geofencing-db-access
  namespace: drone-compliance
spec:
  podSelector:
    matchLabels:
      app: geofencing-db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: geofencing-service
    ports:
    - protocol: TCP
      port: 5432

Die NetworkPolicy stellt sicher, dass nur der Geo-Fencing-Service auf die Datenbank zugreifen kann. Kein anderer Pod im Namespace hat Zugriff -- ein wichtiger Punkt fuer Audits. Mehr zu Netzwerk-Isolation unter Kubernetes Namespace Management.

Policy-as-Code: Flugregeln in OPA/Rego

Open Policy Agent (OPA) eignet sich hervorragend, um regulatorische Regeln deklarativ zu formulieren. Der Flugplan-Validator sendet den Flugplan als JSON an OPA und bekommt eine Entscheidung (allow/deny mit Begruendung) zurueck.

Beispiel einer Rego-Policy fuer grundlegende EASA-Regeln:

# Datei: policies/flight-plan.rego

package drone.flightplan

import future.keywords.if
import future.keywords.in

default allow := false

allow if {
    altitude_ok
    distance_to_airport_ok
    pilot_licensed
    daylight_ok
    not in_restricted_zone
}

altitude_ok if {
    input.max_altitude_m <= 120
}

distance_to_airport_ok if {
    input.min_distance_airport_km >= 5
}

pilot_licensed if {
    input.pilot.license_type in {"A1A3", "A2", "STS"}
    input.pilot.license_expiry > time.now_ns()
}

daylight_ok if {
    input.flight_time_start >= input.location.sunrise_utc
    input.flight_time_end <= input.location.sunset_utc
}

in_restricted_zone if {
    some zone in data.restricted_zones
    geo.within(input.flight_area, zone.geometry)
}

# Detaillierte Ablehnungsgruende
reasons[msg] if {
    not altitude_ok
    msg := sprintf("Maximale Flughoehe %dm ueberschreitet 120m Limit", [input.max_altitude_m])
}

reasons[msg] if {
    not distance_to_airport_ok
    msg := sprintf("Mindestabstand zum Flughafen %dkm unter 5km Minimum",
                   [input.min_distance_airport_km])
}

reasons[msg] if {
    not pilot_licensed
    msg := "Pilotenlizenz ungueltig oder abgelaufen"
}

Der Vorteil dieses Ansatzes: Wenn sich EASA-Regeln aendern, aktualisiert man die Rego-Policies -- nicht den Applikationscode. Neue Regeln koennen als ConfigMap ins Cluster deployed und per OPA Bundle-API hot-reloaded werden.

Datenfluss: Vom Drohnen-Agent bis zum Audit-Log

Der End-to-End-Datenfluss sieht so aus:

1. Drohne/Gateway sendet GPS-Telemetrie alle 1-5 Sekunden per MQTT an einen Mosquitto-Broker im Cluster.
2. Telemetry-Ingester (Kubernetes Deployment) konsumiert MQTT-Messages, schreibt Rohdaten nach MinIO und leitet Positionsdaten an den Geo-Fencing-Service weiter.
3. Geo-Fencing-Service prueft Position gegen PostGIS. Bei Verstoessen: Event an den Alert-Manager und Eintrag ins Audit-Log.
4. Flugplan-Validator prueft vor jedem Flug den eingereichten Plan gegen OPA-Policies. Nur bei "allow" wird der Flug freigegeben.
5. Audit-Logger schreibt alle Compliance-Events (Flugplan-Validierungen, Geo-Fencing-Checks, Verstoesse) als signierte JSON-Dokumente nach MinIO mit konfigurierbarer Retention.

Fuer die Datenpersistenz gibt der Artikel Kubernetes Storage einen guten Ueberblick.

Monitoring und Compliance-Dashboards

Fuer den Betrieb und die Audit-Vorbereitung braucht die Plattform spezifische Metriken und Dashboards. Prometheus sammelt die Metriken, Grafana visualisiert sie.

Relevante Metriken:

Ein Grafana-Dashboard mit diesen Metriken ist das erste, was ein Auditor sehen will. Es demonstriert, dass Compliance nicht nur existiert, sondern aktiv ueberwacht wird. Tipps zum Monitoring-Setup unter Kubernetes Monitoring.

DSGVO: Drohnendaten sind oft personenbezogen

Kameras auf Drohnen erfassen unweigerlich Personen, Kennzeichen und private Grundstuecke. Damit fallen die Daten unter die DSGVO. Wichtige Massnahmen im Kubernetes-Cluster:

Anonymisierung am Edge. Bevor Bilder ins Cluster gelangen, sollten Gesichter und Kennzeichen automatisch unkenntlich gemacht werden. Das reduziert den DSGVO-Scope erheblich. Ein leichtgewichtiges YOLO-Modell auf dem Edge-Gateway (Jetson Nano o.ae.) kann das in Echtzeit leisten.

Retention-Policies. Telemetriedaten und Bilder duerfen nur so lange gespeichert werden, wie es der Zweck erfordert. MinIO Bucket Lifecycle Policies loeschen Daten automatisch nach Ablauf der Frist. Fuer Audit-relevante Daten: laengere Retention, aber zugangsgeschuetzt.

Zugriffskontrolle. RBAC im Cluster stellt sicher, dass nur autorisierte Services und Personen auf Drohnendaten zugreifen. Audit-Logs dokumentieren jeden Zugriff.

Datenschutz-Folgenabschaetzung (DSFA). Fuer systematische Drohnenbefliegung ist eine DSFA nach Art. 35 DSGVO in der Regel Pflicht. Die Kubernetes-Plattform unterstuetzt das, indem sie alle Datenverarbeitungsschritte dokumentierbar und nachvollziehbar macht.

EU AI Act: Auswirkungen auf autonome Drohnen

Der EU AI Act klassifiziert KI-Systeme nach Risiko. Drohnen mit autonomer Navigation, Hinderniserkennung oder autonomer Entscheidungsfindung fallen oft in die Kategorie "Hochrisiko". Das hat direkte Auswirkungen auf das Kubernetes-Setup:

Modellversionierung. Jede Version des KI-Modells muss dokumentiert und reproduzierbar sein. Container-Images mit Tag und Digest sowie Model-Artefakte in MinIO mit Versionierung stellen das sicher.

Logging und Nachvollziehbarkeit. Jede Entscheidung des KI-Systems (z.B. "Hindernis erkannt, Ausweichmanoever eingeleitet") muss geloggt werden. Ein dedizierter AI-Decision-Logger im Cluster schreibt diese Events persistent.

Menschliche Aufsicht. Hochrisiko-KI braucht eine Schnittstelle fuer menschliche Eingriffe. Im Kubernetes-Setup bedeutet das: Ein Operator-Dashboard mit Kill-Switch-Funktionalitaet, das den Flug sofort abbrechen kann.

Konformitaetsdokumentation. Die technische Dokumentation fuer die Konformitaetsbewertung laesst sich zum Grossteil aus dem Cluster generieren: Deployment-Manifeste, NetworkPolicies, RBAC-Konfigurationen, Monitoring-Dashboards und Audit-Logs.

Vergleich: Compliance-Ansaetze

Der Kubernetes-basierte Ansatz spielt seine Staerke aus, wenn die Drohnenflotte waechst und sich Regeln haeufig aendern. Bei einer einzelnen Drohne mit Standard-Open-Category-Fluegen ist die Loesung ueberdimensioniert.

Implementierung: Schritt fuer Schritt

Phase 1 (Monat 1-2): Fundament. Kubernetes-Cluster aufsetzen (3 Nodes reichen fuer den Start), PostGIS deployen, Geo-Fencing-Service als MVP implementieren. Parallel die relevanten EASA-Regeln als Rego-Policies formulieren. Hilfe beim Cluster-Setup unter Production Cluster Setup.

Phase 2 (Monat 3-4): Kern-Compliance. Flugplan-Validator mit OPA-Integration, Audit-Logger mit MinIO-Backend, Pilot-ID-Service. CI/CD-Pipeline aufbauen, damit Policy-Updates automatisch deployed werden. Hinweise zu CI/CD unter Enterprise CI/CD mit Kubernetes.

Phase 3 (Monat 5-6): Haertung und Audit. NetworkPolicies fuer alle Services, RBAC verfeinern, Monitoring-Dashboards fuer Auditoren bauen, Penetration Testing. Die Plattform sollte jetzt audit-ready sein. Zum Thema Penetration Testing: Kubernetes Penetration Testing.

Kosten: Realistisch kalkuliert

Der ROI entsteht primaer durch vermiedene Bussgelder (5-stellig pro Verstoss), eingesparte manuelle Pruefungszeit (10-20 Stunden pro Woche) und schnellere Genehmigungsprozesse. Bei einer Flotte ab 5-10 Drohnen mit regelmaessigen Specific-Category-Fluegen amortisiert sich die Investition typischerweise innerhalb von 12-18 Monaten.

Haeufige Fragen

Brauche ich das auch fuer Open-Category-Fluege? Fuer reine Open-Category-Operationen (unter 25kg, Sichtflug, unter 120m) ist der Compliance-Aufwand gering. Die Plattform lohnt sich primaer ab der Specific Category, wo jeder Flug dokumentiert und genehmigt werden muss.

Kann ich bestehende Drohnen integrieren? Ja. Die meisten kommerziellen Drohnen (DJI, senseFly, etc.) bieten APIs oder SDKs fuer Telemetriedaten. Ein schlanker Agent auf dem Ground-Control-System oder ein Gateway-Service im Cluster uebernimmt die Integration.

Was passiert bei einem Cluster-Ausfall waehrend eines Fluges? Der Drohnen-Agent auf dem Gateway muss autonom funktionieren koennen (lokaler Cache der Geo-Fencing-Daten, Fallback-Regeln). Der Kubernetes-Cluster ist die zentrale Plattform, aber nicht der Single Point of Failure fuer laufende Fluege.

Wie haelt man die Regeln aktuell? EASA veroeffentlicht Regelaenderungen mit Vorlauf. OPA-Policies werden als Git-Repository verwaltet, Review per Pull Request, automatisches Deployment per CI/CD. Neue Luftraumbeschraenkungen (NOTAMs) koennen automatisch ueber die DFS-API (Deutsche Flugsicherung) in die PostGIS-Datenbank importiert werden.

Zusammenfassung

Drohnen-Compliance manuell zu verwalten funktioniert bei einer Drohne. Bei fuenf oder mehr Drohnen mit Specific-Category-Operationen wird es zum Engpass. Kubernetes bietet die Infrastruktur, um Compliance-Regeln als Code zu implementieren, Pruefungen zu automatisieren und Audit-Trails revisionssicher zu speichern.

Der Einstieg funktioniert am besten mit dem Geo-Fencing-Service als MVP -- er hat den hoechsten Compliance-Impact und ist technisch ueberschaubar. Von dort aus wachsen Flugplan-Validierung, Pilot-ID-Management und KI-Compliance organisch dazu.

Wenn Sie eine bestehende Drohnenflotte betreiben und den Compliance-Aufwand reduzieren wollen, koennen wir das in einem Erstgespraech evaluieren. Melden Sie sich ueber unsere Kontaktseite.