Kubernetes Secrets erstellen und in Pods verwenden

Mit kubectl create secret generic --from-file erstellst du ein Kubernetes Secret aus einer lokalen Datei und bindest es über ein Secret-Volume in einen Pod ein. Diese Anleitung zeigt außerdem, wie du eine Änderung durch erneutes Lesen prüfst, ohne den Wert auszugeben. Das Labor verwendet ausschließlich harmlose Demonstrationsdaten, die keinen Zugang zu einem Dienst ermöglichen.

Was sind Kubernetes Secrets und wann brauchst du sie?

Kubernetes Secrets sind API-Objekte für vertrauliche Daten wie Passwörter, Tokens oder Schlüssel, die du getrennt vom Anwendungscode verwaltest und einem Pod beispielsweise als Datei oder Umgebungsvariable zur Verfügung stellst.

Für frei definierte Schlüssel verwendest du den Secret-Typ Opaque. Eine ConfigMap ist dagegen für nicht vertrauliche Konfiguration gedacht, etwa einen Datenbankhost oder einen Betriebsmodus. Ein Secret trennt sensible Werte vom Podmanifest, ersetzt aber kein Sicherheitskonzept: Base64 ist eine Codierung und bietet keine Vertraulichkeit.

Voraussetzungen und Versionen

Die Referenzbasis dieser Anleitung ist zum Stand 2026-10-06 festgelegt:

Diese Versionsangaben beschreiben die dokumentierte Basis. Prüfe vor einer produktiven Übernahme den Kubernetes-Release-Status und die Kompatibilität mit deinem Anbieter. Das Image-Tag ersetzt keine Digest-Festlegung oder Sicherheitsprüfung. Bash und Coreutils musst du für dieses Beispiel nicht auf ältere Versionen zurücksetzen.

Du brauchst eine passende kubeconfig und einen zugänglichen Testcluster. Dein Benutzer muss Namespaces erstellen, lesen und löschen, Secrets erstellen, lesen, auflisten, patchen und löschen sowie Pods erstellen, lesen, auflisten und löschen können. Hinzu kommt Zugriff auf pods/exec; das Warten auf den Pod kann watch benötigen. Die Clusterregeln müssen den beschriebenen Pod zulassen.

Arbeite außerhalb eines Git-Repositories in einem lokalen Verzeichnis, das du für dieses Labor neu anlegst. Falls dir die Einrichtung des Clients fehlt, hilft die Anleitung zu kubectl und Kubernetes-Clustern.

Testbereich vorbereiten

Prüfe zunächst, welchen Cluster deine Befehle ansprechen und welche Client- und Serverversionen vorliegen:

$ kubectl config current-context
$ kubectl version

Fahre nur fort, wenn der Kontext zu deinem vorgesehenen Testcluster gehört. Lege dann den Namespace secrets-labor an:

$ kubectl create namespace secrets-labor

Falls der Namespace bereits existiert, kläre den Namenskonflikt vor dem nächsten Schritt. Verwende keinen vorhandenen Namespace ungeprüft für das Labor. Dasselbe gilt für das lokale Arbeitsverzeichnis: Schlägt seine Erstellung fehl, arbeite nicht einfach darin weiter.

Führe die folgenden Befehle einzeln in Bash aus. umask 077 schränkt die Zugriffsrechte neu angelegter Dateien und Verzeichnisse für andere Benutzer ein:

$ umask 077
$ mkdir secrets-labor-dateien
$ cd secrets-labor-dateien
$ printf '%s' 'demo-eins' > password.txt

demo-eins ist ein öffentlicher Übungswert. Ersetze ihn in diesem Ablauf nicht durch ein echtes Passwort. printf '%s' fügt keinen abschließenden Zeilenumbruch hinzu; kubectl würde einen vorhandenen Zeilenumbruch als Teil des Werts übernehmen. Bleibe für die weiteren Dateioperationen in diesem Arbeitsverzeichnis. In einer neuen Shell musst du dorthin wechseln und umask 077 erneut setzen.

Secret aus einer Datei erstellen

Erstelle das Secret app-zugang im Labor-Namespace. Mit password=./password.txt legst du den Schlüssel explizit auf password fest, unabhängig vom Dateinamen:

$ kubectl create secret generic app-zugang -n secrets-labor --from-file=password=./password.txt
$ kubectl get secret app-zugang -n secrets-labor

Die Standarddarstellung von get secret zeigt unter anderem Namen, Typ und Anzahl der Datenfelder, aber keinen Secret-Wert. Prüfe, dass das Objekt den Typ Opaque und ein Datenfeld besitzt. Nutze für diese Kontrolle keine Ausgabe als YAML oder JSON: Darin stehen die codierten Daten, die sich wieder decodieren lassen. Die zurückhaltende Tabellenansicht beschränkt nicht deine API-Leserechte.

Wie verwendest du ein Secret als Datei im Pod?

Ein Kubernetes Secret verwendest du als Datei im Pod, indem du unter volumes.secret seinen Namen referenzierst und dieses Volume im Container mountest; Pod und Secret müssen dabei im selben Namespace liegen.

Speichere den folgenden Inhalt als secret-leser.yaml im Arbeitsverzeichnis:

apiVersion: v1
kind: Pod
metadata:
  name: secret-leser
  namespace: secrets-labor
spec:
  nodeSelector:
    kubernetes.io/os: linux
  automountServiceAccountToken: false
  restartPolicy: Never
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-leser
      image: busybox:1.37.0-glibc
      command: ["sleep", "3600"]
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: app-zugang
          mountPath: /etc/app-zugang
          readOnly: true
  volumes:
    - name: app-zugang
      secret:
        secretName: app-zugang
        defaultMode: 0440
        items:
          - key: password
            path: password

items projiziert gezielt den Schlüssel password auf die Datei /etc/app-zugang/password. Weitere Secret-Schlüssel würden mit dieser Auswahl nicht gemountet. Im Podmanifest steht nur die Referenz, kein Wert.

Der Container läuft mit Benutzer- und Gruppen-ID 1000. 0440 setzt Leserechte für Eigentümer und Gruppe als Ausgangsmodus; fsGroup: 1000 berücksichtigt die Volume-Gruppenrechte für den Container. Einstellungen wie fsGroup können die endgültigen Dateirechte beeinflussen. Der Mount bleibt schreibgeschützt. Außerdem entfallen automatische ServiceAccount-Tokenmounts: Für dieses Secret-Volume muss der Container selbst nicht die Kubernetes API aufrufen.

Lege den Pod an und warte bis zu 120 Sekunden auf seine Ready-Bedingung:

$ kubectl apply -n secrets-labor -f secret-leser.yaml
$ kubectl wait -n secrets-labor --for=condition=Ready pod/secret-leser --timeout=120s
$ kubectl exec -n secrets-labor secret-leser -- test -s /etc/app-zugang/password

test -s prüft, ob die Datei existiert und größer als null Bytes ist. Ein erfolgreicher Aufruf endet mit Status 0 und gibt keinen Inhalt aus. Er beweist noch nicht, dass eine Anwendung den Wert verarbeitet. Der Container wartet mit sleep 3600 eine Stunde; erledige die folgenden Prüfungen in dieser Zeit.

Was passiert, wenn du ein Kubernetes Secret änderst?

Wenn du ein Kubernetes Secret änderst, aktualisiert Kubernetes ein regulär gemountetes Secret-Volume mit Verzögerung; eine Anwendung muss die Datei erneut lesen, während laufende Container aktualisierte Secret-Umgebungsvariablen erst nach einem Neustart erhalten.

Prüfe zunächst die Bytezahl des ersten Übungswerts im Pod:

$ kubectl exec -n secrets-labor secret-leser -- wc -c /etc/app-zugang/password

Für demo-eins ohne Zeilenumbruch beträgt die Länge neun Bytes. wc -c gibt die Bytezahl und den Dateipfad aus, nicht den Inhalt. Diese Längenprüfung ist für die Demonstrationsdaten gedacht; protokolliere Größen echter Geheimnisse nicht unnötig.

Schreibe nun einen absichtlich längeren Übungswert in dieselbe lokale Datei und aktualisiere denselben Secret-Schlüssel:

$ printf '%s' 'demo-zwei-laenger' > password.txt
$ kubectl create secret generic app-zugang -n secrets-labor --from-file=password=./password.txt --dry-run=client -o yaml | kubectl apply -n secrets-labor -f -
$ kubectl exec -n secrets-labor secret-leser -- wc -c /etc/app-zugang/password

--dry-run=client erzeugt das Manifest lokal; die Pipe übergibt es direkt an apply. Sie transportiert die Base64-codierten Daten. Lass den Pipe-Inhalt weder ausgeben noch protokollieren. Client-Side Apply speichert außerdem Manifestdaten in der Annotation kubectl.kubernetes.io/last-applied-configuration. Beim ersten Apply auf das zuvor per create angelegte Objekt kann ein Hinweis auf die fehlende Annotation erscheinen; apply ergänzt sie. Deshalb ist dieser Ablauf ausdrücklich auf Dummywerte begrenzt. Produktionsupdates gehören in deinen etablierten Secret-Prozess.

Der zweite Wert hat 17 Bytes. Zeigt die Prüfung noch neun Bytes, wiederhole nur den letzten wc-Aufruf nach etwas Wartezeit. Die Verzögerung hängt unter anderem vom kubelet-Synchronisationsintervall und der Cache-Strategie ab. Eine feste Wartezeit bis zur Übernahme lässt sich daraus nicht ableiten.

17 Bytes zeigen in diesem Beispiel den Wechsel zur anderen Länge. Die Prüfung unterscheidet keine beliebigen gleich langen Werte und belegt kein automatisches Reload einer Anwendung. Jeder wc-Aufruf öffnet die Datei erneut; eine Anwendung mit zwischengespeicherten Zugangsdaten braucht einen eigenen Mechanismus zum erneuten Einlesen.

Für die alternative Einbindung als Umgebungsvariable sähe der Ausschnitt unter dem Container beispielsweise so aus:

env:
  - name: APP_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-zugang
        key: password

Der Ausschnitt ist keine eigenständige Ressource und wird für das Dateilabor nicht angewendet. Die Wahl zwischen Datei und Umgebungsvariable hängt von der Anwendung ab. Eine Änderung am Secret rotiert zudem kein Passwort in einer Datenbank oder einem anderen Zielsystem.

Sicherheitsgrenzen im Betrieb beachten

Für den Betrieb brauchst du neben der passenden Einbindung klare Zugriffs- und Speicherregeln. Die Kubernetes-Empfehlungen für Secrets nennen insbesondere Verschlüsselung ruhender Daten und möglichst geringe Rechte.

• Prüfe die Verschlüsselung der Secret-Daten in etcd mit deinem Clusterbetreiber. Sie ist eine Clusterkonfiguration und folgt weder aus Base64 noch aus einem Dateimount.
• Begrenze get, list und watch auf Secrets. Auch list kann den Inhalt liefern. Berücksichtige zusätzlich Pod-Erstellrechte: Wer einen Pod mit einem Secret erzeugen darf, kann den Wert über diesen Pod lesen, selbst ohne direkten Secret-Lesezugriff.
• Gib nur den Containern Zugriff, die den jeweiligen Wert brauchen. Ein eigener Namespace strukturiert den Zugriff, genügt aber allein nicht als Schutz.
• Halte echte Werte und codierte Secret-Manifeste aus Git, Shellargumenten, History und Logs heraus. Auch die Anwendung muss gelesene Daten schützen.

Bei Managed Kubernetes solltest du mit dem Anbieter klären, welche Schutzmaßnahmen der Clusterbetrieb übernimmt und welche Aufgaben bei deinem Team liegen. Dazu gehören Secret-Zugriff, Aktualisierung und das erneute Einlesen durch Anwendungen. Aus der Bezeichnung des Dienstes ergibt sich keine konkrete Verschlüsselungskonfiguration.

Fehler eingrenzen

Beginne mit der Standarddarstellung von Pod und Secret:

$ kubectl get pod secret-leser -n secrets-labor
$ kubectl get secret app-zugang -n secrets-labor

Eine einzelne Berechtigungsfrage kannst du beispielsweise so stellen:

$ kubectl auth can-i create pods -n secrets-labor

Diese Abfrage prüft nur die angegebene Aktion. Sie bestätigt weder sämtliche erforderlichen Rechte noch die Zulässigkeit des Podmanifests unter den Clusterregeln.

Aufräumen und nächste Schritte

Entferne zuerst gezielt den Labor-Pod und das Secret:

$ kubectl delete pod secret-leser -n secrets-labor
$ kubectl delete secret app-zugang -n secrets-labor
$ kubectl get pods,secrets -n secrets-labor

Die letzte Abfrage zeigt nur Pods und Secrets. Prüfe vor der Namespace-Löschung zusätzlich, dass dort keine fremden Workloads oder andere benötigte Ressourcen liegen. Eine Namespace-Löschung entfernt sämtliche Ressourcen darin. Lösche secrets-labor nur, wenn du ihn wie beschrieben neu für dieses Labor angelegt hast:

$ kubectl delete namespace secrets-labor

Lösche anschließend im lokalen Arbeitsverzeichnis ausschließlich die beiden angelegten Dateien:

$ rm -- ./password.txt ./secret-leser.yaml

Den leeren Arbeitsordner kannst du danach manuell entfernen. rm entfernt Dateien, garantiert aber keine sichere physische Löschung ihrer Inhalte.

Für die Übertragung auf deine Anwendung klärst du als Nächstes, wie sie geänderte Zugangsdaten erneut liest, wer Secrets aktualisieren darf und wie Änderungen mit dem Zielsystem abgestimmt werden. Erst diese Entscheidungen machen aus dem gezeigten Dateimount einen geeigneten Ablauf für deinen Betrieb.