Kubernetes: Zertifikat im TLS-Secret austauschen

Kubernetes-Anwendungen beziehen ihr Zertifikat meist aus einem Secret vom Typ kubernetes.io/tls mit den Schlüsseln tls.crt (Serverzertifikat, gefolgt von den Zwischenzertifikaten) und tls.key. Ein Ingress verweist darauf in spec.tls[].secretName, ein Gateway in den certificateRefs seines Listeners. Eine Änderung am Secret ändert die gespeicherten Daten; wann die neuen Daten aktiv werden, entscheidet der Ingress-Controller oder die Anwendung.

VoraussetzungenCopy Anchor Link

Klären Sie zuerst, wem das Secret gehört - sonst wird eine manuelle Änderung überschrieben:

• cert-manager: Verwaltet eine Certificate-Ressource das Secret (kubectl get certificate -A), erneuern Sie über cert-manager, statt das Secret zu bearbeiten.
• Helm oder GitOps (Argo CD, Flux): Maßgeblich sind die Chart-Werte bzw. das Git-Repository - oft verschlüsselt mit Sealed Secrets oder SOPS oder synchronisiert über External Secrets. Ändern Sie das Zertifikat dort und lassen Sie es synchronisieren; eine Live-Änderung wird zurückgesetzt.
• Sonst können Sie das Secret wie unten direkt aktualisieren.

Notieren Sie außerdem Kontext und Namespace, den Namen des Secrets, welche Ingresses, Gateways oder Workloads es nutzen und ob es unveränderlich (immutable) ist:

kubectl -n <namespace> get secret <secret> -o jsonpath='{.immutable}'

Sichern Sie Zertifikat und Schlüssel als Dateien (nicht als YAML - ein exportiertes Secret enthält Felder, an denen ein erneutes Anwenden scheitert):

kubectl -n <namespace> get secret <secret> -o jsonpath='{.data.tls\.crt}' | base64 -d > old-tls.crt
kubectl -n <namespace> get secret <secret> -o jsonpath='{.data.tls\.key}' | base64 -d > old-tls.key
chmod 600 old-tls.key

Zertifikat Schritt für Schritt austauschenCopy Anchor Link

1. Neue Dateien prüfen - der Schlüssel muss zum Zertifikat gehören:

   Copy Text

   openssl pkey -in private.key -pubout | sha256sum
   openssl x509 -in fullchain.pem -noout -pubkey | sha256sum

2. Secret an Ort und Stelle aktualisieren:

   Copy Text

   kubectl -n <namespace> create secret tls <secret> \
     --cert=fullchain.pem --key=private.key \
     --dry-run=client -o yaml | kubectl apply -f -

   Das ersetzt nur die Daten. Löschen und erstellen Sie das Secret nicht neu - das hinterlässt eine Lücke, in der der Ingress kein Zertifikat hat.

3. Unveränderliches Secret: Es lässt sich nicht ändern. Legen Sie ein neues an und stellen Sie den Ingress (oder das Gateway) darauf um:

   Copy Text

   kubectl -n <namespace> create secret tls <secret>-2026 --cert=fullchain.pem --key=private.key
   kubectl -n <namespace> patch ingress <ingress> --type=json \
     -p '[{"op":"replace","path":"/spec/tls/0/secretName","value":"<secret>-2026"}]'

   Löschen Sie das alte Secret, sobald das neue geprüft ist.

4. Aktivierung:

   • Ingress-Controller wie ingress-nginx und Traefik beobachten Secrets und nutzen das neue Zertifikat ohne Neustart.
   • Ein Workload, der das Secret als Volume einbindet, sieht die neuen Dateien nach kurzer Verzögerung - außer bei einem subPath-Mount, der nie aktualisiert wird.
   • Eine Anwendung, die die Dateien nur beim Start liest oder sie über Umgebungsvariablen bekommt, braucht einen Rollout:

   Copy Text

   kubectl -n <namespace> rollout restart deployment/<deployment>
   kubectl -n <namespace> rollout status deployment/<deployment>

Neues Zertifikat prüfenCopy Anchor Link

Zertifikat im Secret prüfen, ohne den Schlüssel auszugeben, dann den Hostnamen:

kubectl -n <namespace> get secret <secret> -o jsonpath='{.data.tls\.crt}' |
  base64 -d | openssl x509 -noout -subject -issuer -enddate -fingerprint -sha256
openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/null

Der erste Befehl zeigt das erste Zertifikat in tls.crt, das Serverzertifikat. Das ausgelieferte Zertifikat muss denselben Fingerabdruck haben, und die Zwischenzertifikate müssen mitgesendet werden. Prüfen Sie auch Events und Logs von Controller und Pods.

RollbackCopy Anchor Link

Spielen Sie die gesicherten Dateien wie in Schritt 2 ein (oder stellen Sie den Ingress nach Schritt 3 wieder auf das alte Secret um), oder machen Sie die Änderung in Git bzw. Helm rückgängig. Wiederholen Sie den Aktivierungsschritt, falls der Workload einen brauchte.

Häufige ProblemeCopy Anchor Link

• tls.crt enthält nur das Serverzertifikat, ohne Zwischenzertifikate.
• Das Secret wurde im falschen Kontext oder Namespace geändert.
• cert-manager, GitOps oder Helm haben das alte Secret wiederhergestellt.
• Die Anwendung liest das Zertifikat nur beim Start, und es gab keinen Rollout.
• Ein subPath-Mount sieht die Änderung nie.
• Weit gefasste RBAC-Rechte erlauben fremden Nutzern oder Workloads, den privaten Schlüssel zu lesen.

Zertifikatstausch mit aethercert automatisierenCopy Anchor Link

Das aethercert-Deployment-Ziel für Kubernetes legt über die API ein Secret vom Typ kubernetes.io/tls an bzw. aktualisiert es und kann rollierende Neustarts für ausdrücklich angegebene Deployments im selben Namespace auslösen.

Unter Deployment-Ziele finden Sie die Felder dieser Vorlage, die Voraussetzungen auf dem Host und den Stand der Verifizierung.

QuellenCopy Anchor Link

• Kubernetes: TLS-Secrets
• Kubernetes: unveränderliche Secrets
• Kubernetes: kubectl rollout
• Kubernetes: bewährte Verfahren für Secrets