Drohnen-Backend mit Kubernetes absichern: Kommunikation, Zertifikate und Anomalie-Erkennung

TL;DR

• Drohnen selbst laufen nicht auf Kubernetes -- aber das gesamte Backend (Telemetrie-Verarbeitung, Steuerungsbefehle, Firmware-Updates) laesst sich als Microservice-Architektur auf Kubernetes betreiben und absichern.
• Sichere Kommunikation zwischen Drohne und Backend basiert auf mTLS oder VPN-Tunneln. cert-manager automatisiert das Zertifikatsmanagement.
• Anomalie-Erkennung laeuft als eigener Service, der Telemetriedaten (GPS, Flugmuster, Signalstaerke) in Echtzeit auswertet.
• NetworkPolicies isolieren die sicherheitskritischen Backend-Services voneinander -- ein kompromittierter Telemetrie-Ingest-Service soll keinen Zugriff auf den Steuerungskanal haben.

Worum es geht (und worum nicht)

Wenn von "Kubernetes fuer Drohnen" die Rede ist, gibt es oft ein Missverstaendnis: Kubernetes laeuft nicht auf der Drohne. Die Flightcontroller-Software (ArduPilot, PX4, DJI-proprietaer) ist auf Embedded-Hardware und operiert unter Echtzeitanforderungen, die Kubernetes nicht erfuellen kann.

Was Kubernetes sehr wohl tun kann: das gesamte Backend orchestrieren. Dazu gehoeren:

• Telemetrie-Ingestion und -Speicherung
• Steuerungsbefehle von der Bodenstation zur Drohne weiterleiten
• Zertifikats- und Identitaetsmanagement
• Firmware-Update-Distribution
• Echtzeit-Anomalie-Erkennung
• Logging, Monitoring und Audit-Trails

Dieses Backend ist der Angriffspunkt. Wer das Backend kompromittiert, kann Telemetriedaten manipulieren, falsche Steuerungsbefehle einschleusen oder Firmware-Updates mit Schadcode verteilen. Deshalb lohnt es sich, hier sauber zu arbeiten.

Architektur: Welche Services laufen im Cluster

Eine typische Drohnen-Backend-Architektur besteht aus vier Schichten:

Die Trennung in separate Namespaces ist nicht optional. Wenn der Telemetrie-Ingestion-Service (der direkt vom Internet erreichbar ist) kompromittiert wird, soll er keinen Zugriff auf den Command-Relay-Service haben, der Steuerungsbefehle an Drohnen sendet.

Sichere Kommunikation mit mTLS

Die Kommunikation zwischen Drohne und Backend muss verschluesselt und authentifiziert sein. Zwei Optionen:

Option A: VPN-Tunnel (WireGuard) Einfach zu implementieren, funktioniert auch bei instabilen Mobilfunkverbindungen. Nachteil: Jede Drohne braucht eine statische WireGuard-Konfiguration, und Key-Rotation ist manuell.

Option B: mTLS (Mutual TLS) Beide Seiten (Drohne und Backend) praesentieren ein Zertifikat. Mehr Aufwand beim Setup, aber flexibler und besser automatisierbar. Das ist der empfohlene Ansatz.

cert-manager uebernimmt die Zertifikatsverwaltung im Cluster. Jede Drohne erhaelt ein Client-Zertifikat von einer internen Certificate Authority:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: drone-ca-issuer
spec:
  ca:
    secretName: drone-ca-key-pair
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: drone-gateway-cert
  namespace: drone-comm
spec:
  secretName: drone-gateway-tls
  issuerRef:
    name: drone-ca-issuer
    kind: ClusterIssuer
  commonName: gateway.drone.internal
  dnsNames:
  - gateway.drone.internal
  - drone-gateway.drone-comm.svc.cluster.local
  duration: 8760h    # 1 Jahr
  renewBefore: 720h  # 30 Tage vor Ablauf erneuern
  privateKey:
    algorithm: ECDSA
    size: 256

Das Gateway-Deployment nutzt dieses Zertifikat und verlangt Client-Zertifikate von den Drohnen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: drone-gateway
  namespace: drone-comm
spec:
  replicas: 2
  selector:
    matchLabels:
      app: drone-gateway
  template:
    metadata:
      labels:
        app: drone-gateway
    spec:
      containers:
      - name: gateway
        image: envoyproxy/envoy:v1.31-latest
        ports:
        - containerPort: 8443
          name: mtls
        - containerPort: 9901
          name: admin
        volumeMounts:
        - name: tls-certs
          mountPath: /etc/envoy/certs
          readOnly: true
        - name: envoy-config
          mountPath: /etc/envoy
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"
      volumes:
      - name: tls-certs
        secret:
          secretName: drone-gateway-tls
      - name: envoy-config
        configMap:
          name: drone-gateway-config

Envoy ist hier die bessere Wahl gegenueber nginx, weil es nativen mTLS-Support hat und die Client-Zertifikat-Informationen (CN, SAN) als Header an die Backend-Services weiterleiten kann. So weiss der Telemetrie-Service, von welcher Drohne die Daten kommen.

Mehr zu Zertifikatsmanagement finden Sie unter Kubernetes Secrets Management mit Vault.

Anomalie-Erkennung als Kubernetes-Service

Die Anomalie-Erkennung analysiert Telemetriedaten in Echtzeit und erkennt verdaechtige Muster:

• Ploetzliche GPS-Spruenge (moegliches GPS-Spoofing)
• Abweichung vom geplanten Flugpfad
• Unerwartete Signalstaerke-Aenderungen (moegliches Jamming)
• Steuerungsbefehle, die nicht von der autorisierten Bodenstation stammen

Die Architektur dafuer: Ein Message Broker (NATS oder Kafka) nimmt die Telemetriedaten entgegen. Ein oder mehrere Processing-Pods konsumieren den Stream und wenden Regeln an.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: anomaly-detector
  namespace: drone-processing
spec:
  replicas: 2
  selector:
    matchLabels:
      app: anomaly-detector
  template:
    metadata:
      labels:
        app: anomaly-detector
    spec:
      containers:
      - name: detector
        image: registry.example.com/drone/anomaly-detector:v2.4.0
        env:
        - name: NATS_URL
          value: "nats://nats.drone-comm.svc.cluster.local:4222"
        - name: ALERT_WEBHOOK
          value: "http://alertmanager.drone-infra.svc.cluster.local:9093/api/v2/alerts"
        - name: GPS_JUMP_THRESHOLD_METERS
          value: "500"
        - name: SIGNAL_DROP_THRESHOLD_DB
          value: "20"
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "2"
            memory: "1Gi"
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 10

Die Schwellenwerte (GPS_JUMP_THRESHOLD_METERS, SIGNAL_DROP_THRESHOLD_DB) muessen auf die spezifische Drohnenflotte kalibriert werden. Zu niedrige Werte fuehren zu Fehlalarmen, zu hohe Werte lassen echte Angriffe durch.

Die Alerting-Pipeline: Anomalie-Detector sendet an Alertmanager, der ueber definierte Routes (Slack, PagerDuty, E-Mail) eskaliert. Bei kritischen Anomalien (z.B. GPS-Spoofing bestaetigt) kann ein automatisches Return-to-Home oder eine Notlandung ausgeloest werden -- das erfordert allerdings eine direkte Integration mit dem Command-Relay-Service und muss extrem zuverlaessig sein.

NetworkPolicies: Defense in Depth

Die NetworkPolicies sind das Rueckgrat der Sicherheitsarchitektur. Grundprinzip: Deny-All als Baseline, dann gezielt oeffnen.

# Deny-All fuer den Kommunikations-Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: drone-comm
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
# Gateway darf von aussen erreicht werden (Ingress-Namespace)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-gateway-ingress
  namespace: drone-comm
spec:
  podSelector:
    matchLabels:
      app: drone-gateway
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: drone-ingress
    ports:
    - port: 8443
      protocol: TCP
---
# NATS darf nur vom Gateway und vom Anomaly-Detector erreicht werden
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nats-access
  namespace: drone-comm
spec:
  podSelector:
    matchLabels:
      app: nats
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: drone-gateway
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: drone-processing
    ports:
    - port: 4222
      protocol: TCP

Die entscheidende Regel: Der Anomalie-Detector im Processing-Namespace darf NATS lesen, aber er darf keinen Traffic an den Command-Relay-Service senden. So kann ein kompromittierter Anomalie-Detector keine falschen Steuerungsbefehle einschleusen.

Fuer eine tiefergehende Betrachtung von NetworkPolicies empfehle ich Kubernetes Network Policies Advanced.

Firmware-Updates sicher verteilen

Over-the-Air (OTA) Firmware-Updates sind ein kritischer Angriffspunkt. Ein manipuliertes Update kann die gesamte Drohne uebernehmen. Deshalb muessen Updates signiert und die Signatur vor der Installation auf der Drohne verifiziert werden.

Der Update-Workflow:

1. Neues Firmware-Image wird in die CI/CD-Pipeline (z.B. ArgoCD oder Tekton) eingecheckt.
2. Die Pipeline baut das Image, signiert es mit einem privaten Schluessel (gespeichert in Vault oder einem Kubernetes Secret).
3. Das signierte Image wird in einen S3-kompatiblen Object Store hochgeladen.
4. Ein Update-Controller-Pod benachrichtigt die Drohnen ueber den MQTT Broker, dass ein neues Update verfuegbar ist.
5. Die Drohne laedt das Update herunter, verifiziert die Signatur mit dem oeffentlichen Schluessel und installiert es.

Der private Signaturschluessel darf nie im CI-System oder im Git-Repository liegen. Externe KMS-Integration (HashiCorp Vault, AWS KMS, Azure Key Vault) ist Pflicht. Mehr dazu unter Kubernetes Secrets Management mit Vault.

Monitoring und Audit-Trails

Fuer ein Drohnen-Backend reicht Standard-Monitoring nicht aus. Sie brauchen drei Ebenen:

Infrastruktur-Monitoring (Prometheus + Grafana): Cluster-Health, Pod-Restarts, CPU/Memory, Netzwerk-Traffic. Standard-Setup, nichts Drohnen-spezifisches.

Applikations-Monitoring (Custom Metrics): Metriken wie drone_connections_active, telemetry_messages_per_second, commands_sent_total, anomaly_alerts_fired. Diese werden von den einzelnen Services exportiert und in Prometheus gesammelt.

Audit-Trail (Loki oder Elasticsearch): Jeder Steuerungsbefehl, jede Authentifizierung, jede Anomalie-Warnung muss geloggt und fuer mindestens 12 Monate aufbewahrt werden. Nicht nur fuer Compliance, sondern auch fuer Forensik nach Vorfaellen. Kubernetes Audit Logging faengt die API-Server-Ebene ab, aber die Applikations-Logs muessen die Services selbst schreiben.

Details zum Monitoring-Setup finden Sie unter Kubernetes Monitoring und Observability.

DSGVO-Aspekte bei Drohnendaten

Drohnen sammeln Daten, die personenbezogen sein koennen: Bilder von Grundstuecken, Bewegungsmuster in der Naehe von Personen, Kennzeichen auf Parkplaetzen. Auch wenn die Daten primaer technischer Natur sind (Inspektionsdaten, Kartenmaterial), muss geprueft werden, ob personenbezogene Daten enthalten sind.

Drei Massnahmen auf Kubernetes-Ebene:

1. Datenklassifizierung per Label: Namespaces und PVCs, die potenziell personenbezogene Daten enthalten, werden mit data-classification: pii-possible gelabelt. Das erleichtert Audits.

2. Aufbewahrungsfristen per CronJob: Ein CronJob loescht Telemetriedaten und Bilder nach der definierten Aufbewahrungsfrist automatisch. Keine manuellen Loeschprozesse.

3. Zugriffsprotokollierung: Jeder Zugriff auf den Object Store (Bilder, Rohdaten) wird geloggt. RBAC stellt sicher, dass nur autorisierte ServiceAccounts und Personen Zugriff haben.

Vergleich: Managed IoT-Plattform vs. Self-Hosted auf Kubernetes

Bevor Sie alles selbst bauen: Es gibt Managed-IoT-Plattformen (AWS IoT Core, Azure IoT Hub, ThingsBoard Cloud), die einiges davon out-of-the-box bieten.

Fuer Flotten unter 20 Drohnen ohne besondere Compliance-Anforderungen ist eine Managed-Plattform oft die bessere Wahl. Ab 50+ Drohnen, bei On-Premise-Anforderungen oder bei sensiblen Daten (kritische Infrastruktur, militaerische Nutzung) lohnt sich der Self-Hosted-Ansatz auf Kubernetes.

Mehr zum Thema Hosting-Entscheidungen finden Sie unter Kubernetes Hosting Kosten im Vergleich.

Typische Fehler

Fehler 1: Drohnen-Zertifikate ohne Rotation. Zertifikate mit 10 Jahren Laufzeit sind kein Sicherheitskonzept. Setzen Sie Laufzeiten von maximal 1 Jahr und automatisieren Sie die Rotation. cert-manager kann das -- aber die Drohne muss das neue Zertifikat auch empfangen und aktivieren koennen.

Fehler 2: Command-Relay ohne Authentifizierung. Steuerungsbefehle muessen digital signiert sein. Ein API-Key allein reicht nicht -- er kann abgefangen werden. Digitale Signaturen mit asymmetrischer Kryptografie stellen sicher, dass nur die autorisierte Bodenstation Befehle senden kann.

Fehler 3: Anomalie-Erkennung als Single Point of Failure. Wenn der Anomalie-Detector crasht, fliegen die Drohnen blind weiter. Mindestens 2 Replicas, Health Checks und ein Fallback-Mechanismus (z.B. automatisches Return-to-Home wenn der Backend-Kontakt laenger als X Minuten abbricht) sind Pflicht.

Fehler 4: Telemetriedaten unverschluesselt im Object Store. Auch at-rest-Verschluesselung ist noetig. MinIO oder S3-kompatible Stores unterstuetzen Server-Side Encryption. Aktivieren Sie es.

Fazit

Ein Drohnen-Backend auf Kubernetes abzusichern erfordert die gleichen Grundlagen wie jede andere Kubernetes-Security-Architektur: mTLS, NetworkPolicies, RBAC, Monitoring. Was hinzukommt, ist die Echtzeit-Komponente (Anomalie-Erkennung) und die Besonderheit, dass am anderen Ende der Verbindung ein physisches Geraet im Luftraum operiert.

Starten Sie mit dem Kommunikationskanal (mTLS via cert-manager), fuegen Sie dann NetworkPolicies und Monitoring hinzu, und bauen Sie die Anomalie-Erkennung schrittweise auf. Versuchen Sie nicht, alles gleichzeitig zu implementieren.

Falls Sie Unterstuetzung bei der Absicherung Ihrer IoT- oder Drohnen-Infrastruktur auf Kubernetes benoetigen, kontaktieren Sie uns unter /kontakt. Wir helfen bei Architektur, Implementierung und Security-Audits.