Reguliertes Kubernetes

Kubernetes-Observability ist im Tutorial-Sinn ein gelöstes Problem. DaemonSet installieren, kubelet scrapen, /var/log/pods tailen, irgendwohin schicken. Jeder Konferenzvortrag behandelt es, jede verwaltete Plattform liefert eine Variante davon mit. Was die Tutorials nicht behandeln, ist die Prüfung, die in einer Bank, einem Versicherer oder einem Spital darauf folgt: Welche dieser Pod-Logs enthalten Kundendaten, wer kann sie lesen, wohin sind sie gegangen — und können Sie belegen, wozu der Collector auf Node 14 am Tag des Vorfalls konfiguriert war?

Diese Fragen sind auf Kubernetes nicht schwieriger als auf VMs. Sie sind schwieriger wahrzunehmen, weil die Abstraktionen der Plattform — Namespaces, kurzlebige Pods, ein Monitoring-Stack im Cluster, der gratis mitkommt — die Entscheidungen über den Umgang mit Daten verdecken, nach denen eine Aufsicht später fragt. Dieser Leitfaden macht sie sichtbar, auf Vanilla-Kubernetes und auf OpenShift, das ein paar eigene hinzufügt.

Fünf Dinge, die das Tutorial-Setup für regulierte Workloads falsch macht

• Namespaces sind Tenants, und der Standard-Collector weiss das nicht. Ein Collector als DaemonSet pro Node sieht jeden Pod auf dem Node, unabhängig vom Namespace. Solange die Pipeline den Namespace nicht als Resource-Attribut stempelt und danach routet, verlassen die Anwendungslogs des Handelstischs und die des HR-Systems den Node in einem Stream zu einem Ziel. Das ist eine Datentrennungs-Feststellung, die nur darauf wartet, gemacht zu werden.
• In den Pod-Logs steckt die PII. Anwendungslogs auf Kubernetes sind stdout, und stdout ist, was die Entwicklerin ausgegeben hat — Request-Bodies, User-Objekte, Tokens in URLs. Die Maskierung muss im Collector auf dem Node passieren, bevor der Datensatz ihn verlässt, denn nichts oberhalb dieses Punkts sieht den Inhalt — PII in Logs maskieren.
• Der mitgelieferte Monitoring-Stack ist nicht der Audit-Trail. Prometheus und Alertmanager, die mit der Plattform kommen, überwachen die Plattform. Sie sind nicht dafür gebaut, Anwendungstelemetrie unter einer Aufbewahrungspflicht zu tragen, aufzubewahren oder zu regieren — und sie als System of Record zu behandeln ist der Weg, auf dem eine Prüfung entdeckt, dass die Beweismittel nach fünfzehn Tagen abgelaufen sind.
• Das Audit-Log des API-Servers ist Beweismittel — und wird meist nicht verschickt. Wer das Deployment gelöscht, wer das Secret gelesen, wer das RBAC-Binding geändert hat: Das steht im kube-apiserver-Audit-Log, und in den meisten Clustern landet es in einer Datei auf der Control Plane, die niemand erfasst. In einem regulierten Bestand gehört es zu den ersten Quellen, die angebunden werden — und in ein anderes Ziel als die Anwendungslogs.
• Egress ist eine Kontrolle, kein Konfigurationsdetail. Ein Collector, der an ein SaaS-Backend exportiert, ist ein Ausgangspfad aus dem Cluster. Er sollte ein bewusster sein — ein bekanntes Gateway, eine NetworkPolicy, die nur diesen Pfad erlaubt, zentral gehaltene Credentials — und nicht vier DaemonSets mit je einer eigenen ausgehenden Verbindung zu einem anderen Anbieter.

Was OpenShift hinzufügt

OpenShift ist Kubernetes mit Meinungen, und drei davon zählen hier:

• Security Context Constraints. Ein Collector, der /var/log/pods tailt, braucht einen hostPath-Mount und eine annähernd privilegierte SCC. OpenShift gewährt das standardmässig nicht, was richtig ist — und es bedeutet, dass die Berechtigungen des Collectors ein explizites, prüfbares Objekt sind statt eines impliziten Standards. Behandeln Sie die SCC als Teil der Beweismittel.
• Eigene Logging- und Tracing-Operatoren. OpenShift liefert einen Logging-Stack und einen Build des OpenTelemetry Collectors als Operatoren mit. Beides sind legitime Optionen. Die vorab zu beantwortende Frage ist, ob die Erfassungsschicht vom Plattform-Operator verwaltet wird (clusterweit, im Lifecycle von Red Hat) oder von Ihrer Flotten-Control-Plane (dieselbe Config wie Ihre VMs und anderen Cluster). Beides auf einem Cluster zu mischen erzeugt genau die „welcher Agent besitzt diese Datei”-Verwirrung aus Eine Strategie, mehrere Backends.
• Projekte als hartes Mandantenmodell. OpenShift-Projekte sind Namespaces mit einer Admission-Schicht darum. Routen Sie Telemetrie nach Projekt, decken sich die Mandantengrenze der Plattform und die der Observability — die Eigenschaft, die Prüfer am liebsten sehen.

Eine Pipeline-Form, die die Prüfung besteht

Konkret tut die Collector-Konfiguration auf jedem Node vier Dinge, die die Tutorial-Version nicht tut:

processors:
  # 1. Tenant stempeln. Der Namespace wird Resource-Attribut auf jedem Datensatz.
  k8sattributes:
    extract:
      metadata: [k8s.namespace.name, k8s.pod.name, k8s.deployment.name]
  # 2. Auf dem Node maskieren, vor dem Egress.
  transform/redact:
    log_statements:
      - context: log
        statements:
          - replace_pattern(body, "[\\w.+-]+@[\\w-]+\\.[\\w.]+", "<email>")
          - replace_pattern(body, "(?i)(bearer\\s+)[a-z0-9._-]+", "$$1<token>")
  batch:

connectors:
  # 3. Nach Tenant routen. Regulierte Namespaces bleiben on-prem; der Rest darf hinaus.
  routing:
    default_pipelines: [logs/onprem]
    table:
      - context: resource
        condition: attributes["k8s.namespace.name"] == "trading"
        pipelines: [logs/onprem]
      - context: resource
        condition: attributes["k8s.namespace.name"] == "platform"
        pipelines: [logs/cloud]

Das vierte Ding steht nicht im YAML: Das YAML kommt von einer autoritativen Stelle. Ein Node, der die Config des letzten Monats ausführt — die ohne Maskierungsregel —, ist in einem regulierten Cluster kein Ordnungsproblem; es ist ein Vorfall mit unmaskierten Daten. Zentrale, versionierte Config, auf jeden Node ausgerollt, mit einer Aufzeichnung, wer sie geändert hat: Das macht aus „wir maskieren PII” eine Kontrolle statt einer Behauptung — Config-Drift erkennen.

Die Quellen, die anzubinden sind — in dieser Reihenfolge

1. Anwendungslogs aus den regulierten Namespaces, auf dem Node maskiert, on-prem geroutet. Hier sitzt die Exposition.
2. Das Audit-Log des API-Servers, in ein Ziel mit der Aufbewahrung, die Ihr Regime verlangt, und mit Zugriff nur für die Personen, die Vorfälle untersuchen.
3. Kubelet- und Node-Metriken, die wenig sensibel sind und dorthin dürfen, wo es am günstigsten ist.
4. Plattformkomponenten zuletzt — sie sind vom mitgelieferten Stack bereits abgedeckt, und sie in Ihre Pipeline zu duplizieren sind Kosten ohne Beweiswert.

Ehrliche Grenzen

• Kurzlebige Pods machen „was lief” schwieriger. Ein Pod, der vier Minuten lebte und ersetzt wurde, hinterlässt keinen Host, den man inspizieren könnte. Die Aufzeichnung dessen, was er emittiert hat und was der Collector damit getan hat, ist das Beweismittel — ein Grund mehr, warum die Collector-Config autoritativ und auditierbar sein muss.
• Multi-Cluster vervielfacht alles. Drei Cluster sind drei Collector-Flotten mit drei Drift-Flächen. Die Antwort ist dieselbe wie bei VMs: eine Control Plane, eine Config pro Rolle, überall ausgerollt — Flottenmanagement.
• Service Meshes und Sidecars verändern das Bild. Betreiben Sie ein Mesh, wandert ein Teil der Telemetrie — und die mTLS-Grenze — in den Sidecar. Das ist eine eigene Entwurfsfrage, und dieser Beitrag behauptet nicht, sie abzudecken.