ConfigMaps und Secrets in Kubernetes

Eines der wesentlichen Merkmale von Kubernetes ist die Fähigkeit, Konfigurationsdaten und sensible Informationen auf sichere und effiziente Weise zu verwalten. In diesem Artikel werfen wir einen Blick auf zwei zentrale Konzepte, die dies ermöglichen: ConfigMaps und Secrets.

Was sind ConfigMaps?

ConfigMaps sind Kubernetes-Objekte, die zur Speicherung von nicht-sensitiven Konfigurationsdaten verwendet werden. Sie ermöglichen es uns, Konfigurationsdateien, Umgebungsvariablen und andere Konfigurationsdetails von der Anwendung selbst zu trennen – und vereinfachen damit deren Verwaltung und Aktualisierung.

Erstellen einer ConfigMap

Es gibt mehrere Möglichkeiten, eine ConfigMap zu erstellen: über YAML-Dateien, die kubectl-Kommandozeile oder direkt über die Kubernetes-API. Hier ein simples Beispiel für eine ConfigMap, die über eine YAML-Datei definiert wird:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  DATABASE_HOST: “example-host”
  DATABASE_USER: "example-user"

Diese ConfigMap kann dann mit dem folgenden Befehl im Cluster erstellt werden:

kubectl apply -f example-configmap.yaml

Nun sind die Konfigurationsdetails in unserem Cluster vorhanden und können von unseren Pods genutzt werden. Zur Einbindung der ConfigMap in unsere Pods gibt es verschiedene Möglichkeiten – bspw. als Umgebungsvariablen oder als Volumes.

Verwendung einer ConfigMap als Umgebungsvariable

Sofern ihr eine kleine Anzahl einfacher Werte für eure Applikationen zur Verfügung stellen möchtet, sind Umgebungsvariablen ein sehr praktikabler Weg. Das folgende Beispiel zeigt die Einbindung unserer ConfigMap in einen Pod:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  containers:
    - name: example-container
      image: example-image
      envFrom:
        configMapRef:
          name: example-configmap

In Fällen, in denen eure Pods nur einzelne Werte aus eurer ConfigMap benötigen, könnt ihr diese auch gezielt einbinden, wie das folgende Beispiel zeigt:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  containers:
    - name: example-container
      image: example-image
      env:
      - name: DATABASE_HOST
        valueFrom:
          configMapKeyRef:
            name: example-configmap
            key: DATABASE_HOST

Mounten einer ConfigMap als Volume

Insbesondere wenn die Konfigurationsdaten umfangreicher werden oder eine große Menge an Daten enthalten, werden Umgebungsvariablen im täglichen Doing unhandlicher. Hier kommen Volumes ins Spiel. Auch hier ist die Einbindung einfach:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  containers:
    - name: example-container
      image: example-image
      volumeMounts: 
        - name: config
          mountPath: “”etc/example-app-config
          readOnly: true
  volumes:
    - name: config
      configMap: 
        name: example-configmap

Was sind Secrets?

Secrets ähneln ConfigMaps, sind jedoch speziell für die Speicherung sensibler Informationen wie Passwörter, Tokens und Keys gedacht. Sie werden kodiert gespeichert und besitzen strikte Zugriffsrechte, sodass sie eine sichere Methode zur Handhabung solcher Daten darstellen.

Erstellen eines Secrets

Auch Secrets können über YAML-Dateien oder kubectl erstellt werden. Hier ein einfaches Beispiel für die Konfiguration eines Secrets:

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
type: Opaque
data:
  DATABASE_PASSWORD: ZXhhbXBsZS1wYXNzd29yZA== # base64 encoding of 'example-password'  ```

Die Base64-Codierung der Daten kann folgendermaßen durchgeführt werden:

```bash
echo -n 'example-password' | base64

Das Secret kann nun mit folgendem Befehl in unser Cluster deployed werden:

kubectl apply -f example-secret.yaml

Bitte beachtet: Kubernetes encodiert die Secrets lediglich base64, verschlüsselt sie jedoch nicht. Wirklich sicher sind sie dadurch also nicht, insbesondere nicht, wenn sie in geteilten Repositories liegen sollen – die Entschlüsselung ist denkbar einfach. Wir empfehlen daher Encrytion Tools wie bspw. SOPS, die eine echte Verschlüsselung zur Aufbewahrung der Secrets in einem Repository bieten und sie dadurch vor unbefugtem Zugriff zu schützen. Zu erwähnen ist außerdem, dass Secrets in Kubernetes selbst immer unverschlüsselt liegen und entsprechend mit eingeschränkten Zugriffsrechten für User mit Zugriff auf das Cluster abgesichert werden müssen.

Verwendung eines Secrets

Wie ConfigMaps können auch Secrets in Pods als Umgebungsvariablen oder als Dateien im Dateisystem eingebunden werden.

Verwendung eines Secrets als Umgebungsvariable:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  containers:
  - name: example-container
    image: example-image
    env:
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: example-secret
          key: DATABASE_PASSWORD

Mounten eines Secrets als Volume:

apiVersion: v1
kind: Pod
metadata:
  name: example-app
spec:
  containers:
    - name: example-container
      image: example-image
      volumeMounts: 
        - name: secret-volume
          mountPath: “”etc/secret-volume
          readOnly: true
  volumes:
    - name: secret-volume
      secret: 
        secretName: example-secret

Immutability von ConfigMaps & Secrets

Alle bisher vorgestellten Konfigurationen von ConfigMaps und Secrets lassen Änderungen der verwendeten Werte zu. In der Praxis ist dies jedoch nicht immer wünschenswert,da unbeabsichtige Änderungen bspw. die Stabilität und Konsistenz des Clusters beeinflussen können. Hier kommt das Manifest-Property immutable ins Spiel:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  DATABASE_HOST: “example-host”
  DATABASE_USER: "example-user"
immutable: true

bzw. für Secrets

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
type: Opaque
data:
  DATABASE_PASSWORD: ZXhhbXBsZS1wYXNzd29yZA==
immutable: true

Deployed in unser Cluster können so Änderungen an den Konfigurationen ausgeschlossen werden, weswegen Immutability zunehmend als Best Practice gilt.

Zu beachten ist dabei allerdings, dass eine nachträgliche Änderung des immutable Properties selbstredend nicht mehr möglich ist. Sollen Werte aus immutable ConfigMaps oder Secrets geändert werden, so müssen die vorhandenen Konfigurationen gelöscht und neu angelegt werden. Zudem erhalten vorhandene Pods einen Mount Point zum gelöschten Secret oder zur gelöschen ConfigMap, daher ist es ratsam, diesen ebenso neu zu erstellen. Ihr solltet entsprechend abwägen, ob bzw. ab welchem Entwichlungsstadium Immutability für euch in Frage kommt.

Fazit

ConfigMaps und Secrets sind essenzielle Objekte in Kubernetes, die es uns ermöglichen, Konfigurationsdaten und sensible Informationen sicher und effizient zu verwalten. Während ConfigMaps ideal für nicht-sensitive Konfigurationsdaten sind, bieten Secrets eine sichere Methode zur Handhabung vertraulicher Daten.

Erste Schritte ConfigMaps und Secrets in Kubernetes