Speichern der Konfiguration und der Geheimnisse

Question

Ich plane, unsere Anwendung (die aus mehreren Microservices besteht) in ein Diagramm zu verpacken.

Im Moment speichern wir für jeden Microservice Geheimnisse und Konfigurationswerte direkt in unseren deployment.yaml Dateien, in ...containers[].env. Alle unsere yaml Dateien sind in Git Repo gespeichert.

Ich habe bemerkt, dass einige populäre Charts verwenden ConfigMap (1, 2) und Secret (1, 2) Kubernetes Objekte bzw. Konfigurationswerte und Geheimnisse zu speichern.

Was einige Vorteile, sei es Ergonomie und/oder Sicherheitsgewinne, der Verwendung von ConfigMap und Secret Objekte?

Ich könnte bereits Vorlagen aus allen yaml Dateien machen, die wir haben, so dass alle fest codierten Werte konfigurierbar und somit während der Vorlagenkompilierungszeit des Helms auflösbar sind.

Da jedoch Kubernetes spezialisierte Objekte zum Speichern von Konfigurations & Geheimnisse bietet, möchte ich configmap.yaml und secrets.yaml Template-Dateien zu rechtfertigen Hinzufügen sowie das Hinzufügen Verweise auf sie aus bestehenden deployment.yaml Dateien.

Answer 1

Configmaps sind sehr allgemeine Konfigurationsdateien. Sie können aus einer Liste von Schlüsselwertpaaren bestehen, sie können aber auch generische Dateien sein. Zum Beispiel können Sie eine nginx-Konfigurationsdatei nginx.conf in einer configmap speichern und sie an die richtige Stelle laden, damit der nginx-Daemon sie lesen kann.

Geheimnisse sollen zur Speicherung sensibler Daten verwendet werden, leider sind Geheimnisse im Moment nicht verschlüsselt, sie sind nur based64-kodiert. Während das hilft, hartcodierte unverschlüsselte Werte aus Ihren Manifesten zu entfernen, hilft das bei der Verschlüsselung überhaupt nicht. Dies sollte besser werden in v1.7

Sie können Umgebungsvariablen in Ihrem Bereitstellungsmanifest festlegen, um auf bestimmte Werte in secrets oder configmaps zu verweisen. Beide sind auch mit kubectl zum Beispiel leicht erzeugt:

• kubectl create secret generic foobar --from-literal=password=foobar
• kubectl create configmap foobar --from-file=foobar.conf

Helm Charts beste Vorgehensweise ist sowohl zu verwenden, finden Sie mariadb chart.

Persönlich, wenn ich eine Datei in einem Pod laden muss, verwende ich eine configmap, und wenn ich mit einer sensiblen env-Variable handle, verwende ich ein Geheimnis, wobei ich bedenke, dass es nicht verschlüsselt ist.