Das passende Training Kubernetes Advanced Training – Networking, Security, Observability & GitOps (3 Tage)
Vault Secrets Operator, Agent Injector oder CSI? Frag nicht nach dem Tool, sondern wo das Secret liegt
Kurze Antwort: Gegen Klartext im Git-Repo helfen dir alle drei gleich gut. Also ist das nicht die Frage.
Die Frage lautet: Darf dein Secret zusätzlich als Kubernetes-Secret im Cluster liegen, also in etcd? Ja? Dann der Vault Secrets Operator mit einer Ressource im Helm-Chart. Nein? Dann Agent Injector oder CSI Provider. Brauchst du Umgebungsvariablen, geht ohne Umbau nur der Operator-Weg: Injector und CSI liefern Dateien.
Die Frage nach der Frage
Im Einführungstraining macht regelmäßig jemand sein Secret mit base64 -d auf. Ein Teilnehmer hat danach nur gefragt: „Und wie macht man es richtig?“ Die Antwort gab’s als Cliffhanger am nächsten Morgen: External Secrets Operator, Secrets-Manager dahinter. Die Geschichte steht bei der Postkarte namens Kubernetes-Secret.
Wer dann HashiCorp Vault hat, steht direkt vor der nächsten Frage: Wie kommt das Passwort aus Vault in den Pod? Operator, Injector oder CSI? Sidecar hier, DaemonSet da, CRD dort. Alles richtig. Hilft beim Entscheiden nur nicht.
Git ist bei allen dreien sauber
Bei GitOps und Helm liegt deine ganze Konfiguration im Git-Repository, und ein Passwort gehört dort nie im Klartext hinein. Das ist der Grund, warum man Vault überhaupt einsetzt.
Meine Regel steht: Ein Credential liegt nie im Klartext im Git-Repo. Und das schaffen alle drei.
Was steht dann im Repo? Ein Abholschein: „Hol das da drüben ab.“ Beim Operator heißt der Schein VaultStaticSecret. Beim Injector sind’s ein paar Annotationen am Pod. Beim CSI Provider eine SecretProviderClass. Drei Formulare, gleicher Inhalt: ein Pfad im Vault, kein Wert. Wie so ein Schein sauber ins Chart kommt, zeige ich im Artikel über Helm-Values, ConfigMap oder Secret.
Der Unterschied liegt woanders. Nämlich da, wo das Secret am Ende landet.
Im Pod liegt das Passwort sowieso im Klartext, bei allen dreien. Deine Anwendung will es ja benutzen. Die eigentliche Frage ist also nur: Gibt es zusätzlich ein Kubernetes-Secret, also eine Kopie in etcd? Und in Standard-Kubernetes ist etcd unverschlüsselt, bis du die Verschlüsselung selbst einschaltest.
| Weg | Wo das Secret landet | Was es im Betrieb kostet |
|---|---|---|
| Vault Secrets Operator (VSO) | Kubernetes-Secret, laut HashiCorp-Doku „Persisted in etcd (default)“ | ein Operator im Cluster; Lizenz BUSL 1.1; ohne etcd-Kopie nur im CSI-Modus mit Vault Enterprise |
| Agent Injector | Datei in einem Arbeitsspeicher-Volume im Pod, kein Secret-Objekt | ein Agent-Container in jedem Pod, der per Annotation Secrets bekommt |
| CSI Provider | Datei im CSI-Volume im Pod; Sync als Kubernetes-Secret optional | CSI-Treiber und Provider als DaemonSets auf jedem Node, der Treiber läuft privilegiert |
Darf es in etcd? Dann Operator
Für Helm und GitOps ist das mein Standardweg. Im Chart steht der Abholschein, der Operator holt den Wert und legt ein ganz normales Kubernetes-Secret an. Deine Anwendung merkt davon nichts. Kein Untermieter im Pod, keine Annotationen, kein Umbau.
Den Preis kennst du jetzt: eine Kopie in etcd. Also etcd verschlüsseln (manche Managed-Angebote wie EKS machen das inzwischen von selbst) und per RBAC regeln, wer im Namespace Secrets lesen darf. Hausaufgabe, kein Grund zum Weglaufen.
Und wer im Namespace Pods anlegen darf, kommt laut Kubernetes-Doku sowieso an die Secrets ran. Mit dem passenden ServiceAccount auch bei Injector und CSI. Keine Extra-Strafe für den Operator.
Statt des VSO geht auch der External Secrets Operator, der mit vielen Tresoren spricht, darunter HashiCorp Vault. Den Vergleich der beiden Operatoren mit Sealed Secrets findest du in Sealed Secrets oder External Secrets Operator?. Beide landen im selben Ergebnis: ein Kubernetes-Secret in etcd.
Darf es nicht in etcd? Dann Injector oder CSI
Gibt es eine Vorgabe, dass Secrets nie als Objekt im Cluster liegen dürfen, sind Injector und CSI dein Weg. Mit Vault Enterprise geht noch der CSI-Modus des VSO. In HashiCorps eigener Vergleichstabelle hat übrigens nur der Injector das Häkchen bei „nur flüchtige Volumes“.
Ganz ehrlich, das ist kein Gratis-Upgrade. Beim Injector zieht in jeden Pod, der Secrets bekommt, ein Agent als Untermieter ein. Der braucht Speicher und Rechenzeit, hält dafür aber die Datei aktuell. Lässt du nur den Init-Container laufen, ist er weg, die Aktualisierung aber auch.
Beim CSI Provider läuft auf jedem Node ein Treiber mit privilegiertem Zugriff. Und deine Anwendung bekommt in beiden Fällen eine Datei statt einer Umgebungsvariable. Beim Injector machst du daraus per source im Startbefehl wieder Variablen. Geht, ist aber Bastelei am Container.
Wie du den Vault Secrets Operator und den Agent Injector an einen Live-Cluster anbindest, zeige ich dir im Kubernetes-Advanced-Training.