Sichere Container im Blick: Mit Admission Controllers Container Drift erkennen

Bei Box nutzen wir Kubernetes (K8s), um Hunderte von Mikrodiensten zu verwalten, die es uns ermöglichen, Daten im Petabyte-Maßstab zu streamen. Im Rahmen unseres Deployment-Prozesses setzen wir kube-applier als Teil der GitOps-Workflows mit deklarativer Konfiguration und automatisierten Deployments ein. Entwickler deklarieren ihre K8s-Anwendungen in einem Git-Repository, welches eine Code-Überprüfung und automatische Checks erfordert, bevor Änderungen in unseren K8s-Clustern zusammengeführt und angewendet werden können. Mit kubectl exec und ähnlichen Befehlen können Entwickler jedoch direkt mit laufenden Containern interagieren und diese aus ihrem deployten Zustand verändern. Diese Interaktion könnte die Änderungs- und Code-Überprüfungsprozesse, die in unseren CI/CD-Pipelines durchgesetzt werden, untergraben. Zudem erlaubt es, dass solche betroffenen Container langfristig im Produktionsumfeld weiterhin Traffic erhalten.

Um dieses Problem zu lösen, haben wir ein eigenes K8s-Komponenten entwickelt, das wir kube-exec-controller nennen, zusammen mit dem dazugehörigen kubectl-Plugin. Diese arbeiten zusammen, um potenziell veränderte Container (verursacht durch interaktive kubectl-Befehle) zu erkennen und zu beenden sowie die Interaktionsereignisse direkt den Ziel-Pods zur besseren Sichtbarkeit zu offenbaren.

Admission Control für interaktive kubectl-Befehle

Sobald eine Anfrage an K8s gesendet wird, muss sie vom API-Server authentifiziert und autorisiert werden, um fortzufahren. Darüber hinaus hat K8s eine separate Schutzschicht namens Admission Controllers, die die Anfrage abfangen kann, bevor ein Objekt in etcd gespeichert wird. Es gibt verschiedene vordefinierte Admission Controls, die in die API-Server-Binärdatei kompiliert sind (z.B. ResourceQuota zur Durchsetzung harter Ressourcennutzungsgrenzen pro Namespace). Außerdem gibt es zwei dynamische Admission Controls namens MutatingAdmissionWebhook und ValidatingAdmissionWebhook, die verwendet werden, um K8s-Anfragen entweder zu mutieren oder zu validieren. Letzteres haben wir übernommen, um Container Drift zur Laufzeit zu erkennen, die durch interaktive kubectl-Befehle verursacht wird. Dieser gesamte Prozess kann in drei Schritte unterteilt werden, die im Folgenden detailliert erklärt werden.

1. Interaktive kubectl-Befehlsanfragen zulassen

Zunächst mussten wir einen Validating Webhook aktivieren, der qualifizierte Anfragen an kube-exec-controller sendet. Um den neuen Validierungsmechanismus speziell für interaktive kubectl-Befehle hinzuzufügen, haben wir die Regeln des Webhooks mit Ressourcen als [pods/exec, pods/attach] und Operationen als CONNECT konfiguriert. Diese Regeln teilen dem API-Server des Clusters mit, dass alle exec- und attach-Anfragen unserem Admission Control Webhook unterliegen sollten. In dem von uns konfigurierten ValidatingAdmissionWebhook haben wir einen service-Referenz angegeben (kann auch durch url ersetzt werden, die den Standort des Webhooks angibt) und caBundle, um die Validierung seines X.509-Zertifikats zu ermöglichen, beides unter der clientConfig-Strophe.

Hier ist ein kurzes Beispiel, wie unser ValidatingWebhookConfiguration-Objekt aussieht: yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: name: example-validating-webhook-config webhooks:

• name: validate-pod-interaction.example.com sideEffects: None rules:
  • apiGroups: [""] apiVersions: [""] operations: [“CONNECT”] resources: [“pods/exec”, “pods/attach”] failurePolicy: Fail clientConfig: service:

Quelle: Kubernetes Blog