ConfigMaps und Secrets in Kubernetes: Grössengrenzen, Verbreitung von Aktualisierungen und was ein Secret nicht schützt

Worum es geht

Eine ConfigMap hält nicht vertrauliche Schlüssel-Wert-Daten; ein Secret hält eine kleine Menge sensibler Daten. Beide werden von Pods als Umgebungsvariablen, als über diese Variablen weitergereichte Kommandozeilenargumente, oder als Dateien in einem eingebundenen Volume konsumiert. Die ConfigMap-Dokumentation (zitiert) hält fest, dass eine ConfigMap nicht dafür ausgelegt ist, grosse Datenmengen zu halten, und dass ihre Daten 1 MiB nicht überschreiten dürfen; die Secret-Dokumentation (zitiert) setzt dieselbe Grenze von 1 MiB pro Secret. Beide Objekte können als immutable markiert werden; danach lassen sich ihre Daten nicht mehr ändern, und das kubelet beobachtet sie nicht mehr.

Warum es wichtig ist

Zwei Eigenschaften werden regelmässig missverstanden. Erstens die Verbreitung von Aktualisierungen: Laut der zitierten Dokumentation wird eine als Volume konsumierte ConfigMap irgendwann nach dem periodischen Sync des kubelet zuzüglich dessen Cache-Verbreitungsverzögerung aktualisiert, während als Umgebungsvariablen konsumierte ConfigMaps nicht automatisch aktualisiert werden und einen Neustart des Pods erfordern, und ein Container, der eine ConfigMap über subPath einbindet, nie Aktualisierungen erhält. Zweitens die Vertraulichkeit: Secrets werden standardmässig unverschlüsselt in etcd gespeichert; wer API-Zugriff hat, kann ein Secret abrufen oder ändern, wer etcd-Zugriff hat, kann es lesen, und wer in einem Namespace einen Pod erstellen kann, kann über diesen Pod jedes Secret in diesem Namespace lesen. Base64 ist eine Kodierung, kein Schutz.

So wird es angewendet

• Konfiguration, die sich mit dem Release ändert, im Image oder im Manifest belassen, und nur umgebungsspezifische Werte in ConfigMaps legen; grosse Dateien anderswo versionieren.
• Als Volume ohne subPath einbinden, wenn die Anwendung Dateien neu einlesen kann; andernfalls bei Änderung ein Rollout auslösen, etwa indem die ConfigMap in eine Pod-Annotation gehasht wird, sodass sich die Deployment-Vorlage ändert.
• Die Schritte befolgen, die die Secret-Dokumentation auflistet: Verschlüsselung im Ruhezustand für Secrets aktivieren, RBAC-Regeln schreiben, die get auf Secrets nur den Service-Accounts gewähren, die sie brauchen, den Zugriff auf Secrets auf bestimmte Container beschränken, und einen externen Secret-Speicher in Betracht ziehen.
• Release-gebundene ConfigMaps und Secrets als immutable markieren und pro Version ein neues Objekt erstellen; das reduziert zudem die Watch-Last auf dem API-Server.
• Secret-Objekte nie in der CI-Ausgabe ausgeben: kubectl get secret -o yaml zeigt die base64-Form, die sich trivial dekodieren lässt (kubectl describe verbirgt die Werte und zeigt nur deren Grössen).

Stolpersteine

Namespace-Geltungsbereich: Ein Pod kann nur Secrets im eigenen Namespace referenzieren. Die ConfigMap-Anleitungsseite (zitiert) hält fest, dass eine referenzierte, aber nicht existierende ConfigMap oder ein solcher Schlüssel den Start des Pods verhindert, sofern die Referenz nicht als optional markiert ist; dasselbe Feld optional existiert auch für Secret-Referenzen. Umgebungsvariablen werden von jedem Kindprozess geerbt und landen tendenziell in Diagnoseausgaben; Dateien mit restriktiven Modi sind die sicherere Projektion für Anmeldedaten.