Kubernetes ConfigMaps sicher verwenden

ConfigMaps sind API-Objekte in Kubernetes, mit denen Daten in Schlüssel-Wert-Paaren gespeichert werden. Im Grunde handelt es sich um Wörterbücher mit Konfigurationseinstellungen. Zu den Informationen, die Sie in einer ConfigMap erwarten können, gehören Hostnamen, öffentliche Zugangsdaten, Verbindungszeichenfolgen und URLs.

Eine ConfigMap entkoppelt den Anwendungscode von den Konfigurationen. So lassen sich diese ändern, ohne die Anwendung zu beeinträchtigen. Sie können damit beispielsweise unterschiedliche Konfigurationen für Entwicklungs-, Test- und Produktionsumgebungen festlegen.

Beachten Sie jedoch, dass die Verwendung von ConfigMaps Sicherheitsrisiken bergen kann, da ConfigMaps die darin gespeicherten Daten nicht verschlüsseln. Daher müssen wir wissen, wann sich ConfigMaps am besten eignen und wann sie nicht ausreichend sicher sind.

In diesem Artikel erfahren Sie, wie ConfigMaps funktionieren, wie Sie sie sicher verwenden und in welchen Fällen Sie auf andere, sicherere Datenspeicher zurückgreifen sollten.

ConfigMaps in Kubernetes

Bevor wir uns ansehen, wie Sie ConfigMaps verwenden, werfen wir einen Blick auf ihre Funktionsweise und ihre Rolle in Kubernetes.

Funktionsweise von ConfigMaps

ConfigMaps speichern Schlüssel-Wert-Paare als Klartext- und Binärdaten. Damit unterscheiden sie sich von anderen Kubernetes-Objekten, die spec fields verwenden. ConfigMaps können Binärdaten als Base64-codierte Zeichenfolgen und Klartextdaten als UTF-8-Bytefolgen speichern.

Der Cluster kann auf folgende Weise auf ConfigMaps zugreifen:

• Sie als Daten-Volume einbinden.

• Pods im selben Kubernetes-Namespace greifen remote darauf zu.

• Sie von Pods trennen, damit andere Komponenten des Kubernetes-Clusters sie verwenden können.

Pods können ConfigMaps als Konfigurationsdateien, Umgebungsvariablen oder Befehlszeilenargumente verwenden.

Beachten Sie bei der Arbeit mit ConfigMaps die begrenzte Größe von 1 MB. Für größere Datensätze sollten Sie andere Speicheroptionen wie Datenbanken, separate Dateieinbindungen oder Dateidienste in Betracht ziehen.

Die Rolle von ConfigMaps

Die wichtigste Aufgabe von ConfigMaps ist es, Anwendungen portabel zu machen, indem sie den Anwendungscode von den Konfigurationseinstellungen trennen. Dadurch lässt sich eine Anwendung effizient von einer Entwicklungs- in eine Testumgebung und schließlich in eine Produktionsumgebung migrieren.

Sehen wir uns an, wie eine ConfigMap bei der Arbeit mit Kubernetes helfen kann. Nehmen wir für dieses Beispiel an, wir entwickeln eine Anwendung lokal und möchten sie mit Managed-Kubernetes-Service-Anbietern bereitstellen.

Um lokal auf die Datenbank zuzugreifen, müssen wir die Umgebungsvariable DATABASE_HOST auf localhost oder 127.0.0.1 setzen. Bei der Migration in eine Produktionsumgebung müssen wir den Wert der Variablen so ändern, dass die Datenbankkomponente erreichbar ist.

ConfigMaps sicher verwenden

Bevor wir beginnen, finden Sie hier die Voraussetzungen zum Erstellen einer ConfigMap in einem lokalen Kubernetes-Cluster:

• Die neueste Version von Docker Desktop

• Minikube

• Kubectl

• Ein Code-Editor, z. B. VS Code.

In diesem Beispiel erstellen wir eine ConfigMap in YAML und binden sie als Volume ein. So können wir sie auf dieselbe Weise wie eine Kubernetes-Ressource erstellen.

Erstellen Sie eine Datei mit dem Namen mongo-config.yaml und fügen Sie den folgenden Code hinzu:

1kind: ConfigMap
2apiVersion: v1
3metadata:
4  name: test-configmap
5data:
6  # Setting the configuration as key-value properties
7  database: mongodb
8  database_uri: mongodb://localhost:8080
9keys: |
10  image.public.key=554
11  rsa.public.key=36

Erstellen Sie anschließend mit dem folgenden Befehl aus der oben genannten Datei eine ConfigMap:

1kubectl apply -f mongo-config.yaml

Sehen wir uns nun an, wie Sie die ConfigMap verwenden. In diesem Beispiel nutzen wir die oben erstellte ConfigMap mit Umgebungsvariablen. Fügen Sie zum Verwenden der ConfigMap die Eigenschaft envFrom wie im folgenden Code gezeigt in das YAML des Pods ein:

1kind: Pod
2apiVersion: v1
3metadata:
4  name: pod-variables-env
5spec:
6  containers:
7    - name: configmap-var
8      image: nginx:1.7.9
9      envFrom:
10        - configMapRef:
11          name: test-configmap

Im obigen Codeausschnitt haben wir envFrom verwendet, um aus einem Container auf die Informationen der ConfigMap zuzugreifen.

Im letzten Schritt binden wir die ConfigMap an Pods. Diese erstellen wir mit dem folgenden Befehl:

1kubectl exec -it pod-variables-env sh

Dadurch steht die ConfigMap Containern als Umgebungsvariable zur Verfügung.

Secrets in Kubernetes

Secrets werden oft als sichere Alternative zu ConfigMaps dargestellt, da sie einige Gemeinsamkeiten aufweisen:

• Beide speichern Daten in Schlüssel-Wert-Paaren.

• Pods können beide als Dateien in einem Volume verwenden.

• Beide können als Umgebungsvariablen verwendet werden, auch wenn das keine gute Idee ist.

• Beide sind Objekttypen, auf die über einen API-Server zugegriffen wird.

• Beide sind auf 1 MB begrenzt und daher für umfangreiche Daten ungeeignet.

Secrets sind Objekte, die dafür vorgesehen sind, vertrauliche Daten in Kubernetes zu verschlüsseln und zu speichern. Zu den Daten, die in Secrets gespeichert werden sollten, gehören Passwörter, API-Schlüssel, Tokens, Datenbank-Verbindungszeichenfolgen und Ähnliches. So lassen sich vertrauliche Daten vom Anwendungscode trennen. Dadurch sinkt das Risiko, dass sensible Daten offengelegt werden und der Cluster und die Anwendung gefährdet sind. Secrets sollten Sie nicht für Umgebungsvariablen verwenden. Liz Rice und Michael Hausenblasbokk schreiben in ihrem Buch Kubernetes Security:

• Umgebungsvariablen werden bei Abstürzen oder Fehlern oft in Logs ausgegeben.

• kubectl describe pod gibt Werte von Umgebungsvariablen im Klartext aus.

• docker inspect gibt Werte von Umgebungsvariablen im Klartext aus.

Je nachdem, welche Daten vertraulich bleiben sollen, stehen verschiedene Secret-Typen zur Auswahl. Am häufigsten wird Opaque verwendet, das beliebige benutzerdefinierte Daten speichert. Für die einfache Authentifizierung verwenden wir den Typ basic-auth.

Standardmäßig werden Secrets nicht verschlüsselt in etcd, dem Speicher des API-Servers, abgelegt. Alle Personen mit API-Zugriff können auf Secrets zugreifen und sie ändern. Um den Zugriff einzuschränken, müssen Sie Folgendes tun:

• Aktivieren Sie die Verschlüsselung von Secret-Daten im Ruhezustand. Viele, wenn nicht alle, Anbieter verwalteter Kubernetes-Dienste bieten diese Option beim Erstellen des Clusters an.

• Aktivieren und konfigurieren Sie RBAC-Regeln, um Lese- und Schreibzugriffe einzuschränken.

• Beschränken Sie mit RBAC, wer Secrets erstellen darf.

ConfigMaps und Secrets im Vergleich

ConfigMaps und Secrets haben zwar Gemeinsamkeiten, sind aber nicht dasselbe. Je nach Sicherheitsanforderungen eignen sie sich für unterschiedliche Anwendungsfälle.

Der Hauptunterschied zwischen ConfigMaps und Secrets liegt in der Vertraulichkeit der darin gespeicherten Daten. Secrets verschleiern Daten durch Base64-Codierung, während ConfigMap-Daten im Klartext vorliegen. Beachten Sie, dass Sie auch Klartext in ConfigMaps als Base64-codierte Zeichenfolgen speichern können.

Ein weiterer Unterschied besteht darin, dass es in Kubernetes mehrere Secret-Typen gibt. Sie können den Typ des Secrets passend zu den sensiblen Daten auswählen, die Sie schützen möchten.

Wann Sie ConfigMaps verwenden sollten

ConfigMaps eignen sich hervorragend, um Anwendungsdaten vom Konfigurationscode zu entkoppeln. Nehmen wir beispielsweise an, wir haben einen Anwendungskontainer für Mitarbeiterdaten, der eine Verbindung zu einer MySQL-Datenbank herstellt. Wenn wir die Datenbankverbindungskonfiguration fest in den Container einprogrammieren, kann es beim Wechsel von der Entwicklungs- in die Produktionsumgebung zu Problemen kommen. Denn in der Produktionsumgebung können wir nicht die Entwicklungsdatenbank verwenden.

Mit einer ConfigMap lässt sich der Wechsel der Anwendungsumgebung vereinfachen, indem die Konfigurationsdaten in einer separaten Datei außerhalb des Containers gespeichert werden. Bei einem Umgebungswechsel muss dann lediglich der Datenbankverweis geändert werden.

Die in ConfigMaps enthaltenen Daten lassen sich mit kubectl describe configmaps <name> ganz einfach anzeigen. Da sie im Klartext vorliegen, können sie ebenso leicht bearbeitet werden. Diese Funktionen erleichtern zwar das Anpassen der Konfiguration an die Umgebung (Entwicklung, Test oder Produktion), machen ConfigMaps aber ungeeignet für sensible Daten. Diese sollten in Kubernetes-Secrets gespeichert werden, damit sie verschlüsselt und Zugriffe darauf eingeschränkt werden können.

Wann Sie Secrets verwenden sollten

Wie ConfigMaps entkoppeln auch Secrets die Daten vom Anwendungscode. So lässt sich verhindern, dass sensible Daten beim Erstellen oder Ändern von Pods offengelegt werden.

Kehren wir nun zu unserem Beispiel mit den Mitarbeiterdaten zurück. In diesem Szenario benötigt die Anwendung einen Serverhost, einen Port, einen Datenbanknamen, einen Benutzernamen und ein Passwort, um eine Verbindung zur Datenbank herzustellen.

Vergleichen wir zwei Codeausschnitte. Der erste zeigt, wie eine ConfigMap Daten verarbeitet, der zweite, wie ein Secret Daten verarbeitet.

So sieht eine ConfigMap aus:

1db-configmap.yaml
2
3apiVersion: v1
4kind: ConfigMap
5# ConfigMap data
6metadata:
7  name: employee-database-conf
8  namespace: default
9# Database configurations
10data:
11  server.host: "10.07.11.653"
12  server.port: "3030"
13  db.name: employees_data

Die obige ConfigMap-YAML-Datei enthält nicht vertrauliche Daten zur Datenbankverbindung: Serverhost, Serverport und Datenbankname.

So würde eine Secret-Datei aussehen:

1db-secret.yaml
2
3apiVersion: v1
4kind: Secret
5# Secret Data
6metadata:
7  name: employee-database-auth
8  namespace: default
9# The type of Secret 
10type: kubernetes.io/basic-auth
11# Secret data
12stringData:
13  username: dGhlYWRtaW4= //theadmin
14  password: YWRtaW5wYXNz //adminpass

In der obigen Secret-YAML-Datei ist als Secret-Typ basic-auth angegeben, der Anmeldedaten für die einfache Authentifizierung verarbeitet. stringData enthält die Daten, die vertraulich bleiben sollen. In diesem Fall sind das Benutzername und Passwort.

Im obigen Beispiel haben Secrets dazu beigetragen, den Benutzernamen und das Passwort für die Datenbank vertraulich zu halten. So wird außerdem verhindert, dass diese Informationen beim Erstellen oder Ändern des Pods offengelegt werden.

Sicherheit von Kubernetes-Konfigurationen

Eine ConfigMap ist ein API-Objekt in Kubernetes, das nicht vertrauliche Konfigurationsdaten in Schlüssel-Wert-Paaren speichert. Standardmäßig werden die Daten im Klartext abgelegt. So lässt sich der Anwendungscode von den Konfigurationen trennen. Auch Secrets sind API-Objekte in Kubernetes. Sie verschlüsseln und speichern sensible Konfigurationsdaten in Schlüssel-Wert-Paaren. Dadurch sinkt das Risiko, dass sensible Daten offengelegt werden und der Cluster und die Anwendung gefährdet sind.

Wenn Sie einen sicheren Kubernetes-Cluster erstellen möchten, der Anwendungscode und Konfigurationen entkoppelt, speichern Sie sensible Daten in Secrets und nicht vertrauliche Konfigurationen in ConfigMaps. Aktivieren Sie außerdem unbedingt RBAC, um den Zugriff auf ConfigMaps und Secrets einzuschränken. So sinkt das Risiko, dass Konfigurationen unbefugt abgerufen oder geändert werden.