Sicheres Secrets-Management in Kubernetes implementieren — mit SealedSecrets fuer GitOps, External Secrets Operator fuer Cloud-Secret-Manager und Rotationsstrategien. TLS-Zertifikate, API-Schluessel und Credentials mit Verschluesselung im Ruhezustand und RBAC-Kontrollen verwalten. Einsatz beim Speichern sensibler Konfiguration fuer Kubernetes-Anwendungen, beim Implementieren von GitOps wo Secrets versioniert werden muessen, bei der Integration mit AWS Secrets Manager oder Azure Key Vault, beim Rotieren von Credentials ohne Ausfallzeit oder bei der Migration von Klartext-Secrets zu verschluesselten Loesungen.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Sicheres Secrets-Management in Kubernetes implementieren — mit SealedSecrets fuer GitOps, External Secrets Operator fuer Cloud-Secret-Manager und Rotationsstrategien. TLS-Zertifikate, API-Schluessel und Credentials mit Verschluesselung im Ruhezustand und RBAC-Kontrollen verwalten. Einsatz beim Speichern sensibler Konfiguration fuer Kubernetes-Anwendungen, beim Implementieren von GitOps wo Secrets versioniert werden muessen, bei der Integration mit AWS Secrets Manager oder Azure Key Vault, beim Rotieren von Credentials ohne Ausfallzeit oder bei der Migration von Klartext-Secrets zu verschluesselten Loesungen.
Erwartet: Secrets im Ruhezustand in etcd verschluesselt. Hexdump zeigt verschluesselte Daten, keinen Klartext. KMS-Integration fuer cloud-verwaltete Cluster konfiguriert.
Bei Fehler: Bei API-Server-Startfehlern Syntax und Schluessel-Format der encryption-config.yaml pruefen (muss base64-kodierter 32-Byte-Schluessel sein). Bei KMS-Fehlern IAM-Berechtigungen fuer kms:Decrypt und kms:Encrypt pruefen.
Schritt 2: Sealed Secrets fuer GitOps installieren und konfigurieren
# Apply sealed secret to cluster
kubectl apply -f mysealedsecret.yaml
# Verify regular Secret was created automatically
kubectl get secret mysecret -o yaml
# Decode secret to verify values
kubectl get secret mysecret -o jsonpath='{.data.username}' | base64 -d
# Commit sealed secret to Git (safe, encrypted)
git add mysealedsecret.yaml
git commit -m "Add database credentials as sealed secret"
Erwartet: Sealed Secrets Controller laeuft im kube-system Namespace. Oeffentliches Zertifikat abgerufen. Kubeseal verschluesselt Secrets mit dem oeffentlichen Schluessel. Nur der Controller kann entschluesseln (hat privaten Schluessel).
Bei Fehler: Bei Namespace-Missmatch-Fehlern: Sealed Secrets sind standardmaessig namespace-gebunden; --scope cluster-wide fuer cross-namespace Secrets verwenden. Wenn der private Schluessel verloren geht, koennen versiegelte Secrets nicht entschluesselt werden; Controller-Schluessel sichern mit kubectl get secret -n kube-system sealed-secrets-key -o yaml > sealed-secrets-backup.yaml.
Erwartet: External Secrets Operator laeuft. SecretStore mit Cloud-Provider-Credentials konfiguriert. ExternalSecret-Ressourcen erstellen automatisch Kubernetes-Secrets durch Abrufen aus Cloud-Secret-Managern. Secrets werden stuendlich aktualisiert.
Bei Fehler: Bei Authentifizierungsfehlern IAM-Rolle/Service-Account-Annotationen und Vertrauensrichtlinien pruefen. Bei Synchronisierungsfehlern ExternalSecret-Status mit kubectl describe externalsecret pruefen.
Schritt 4: Zertifikatsverwaltung mit cert-manager implementieren
TLS-Zertifikatsbereitstellung und -erneuerung mit cert-manager automatisieren.
# Install cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
# Verify installation
kubectl get pods -n cert-manager
# ... (see EXAMPLES.md for complete configuration)
apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:myapp-ingressannotations:cert-manager.io/cluster-issuer:"letsencrypt-prod"# ... (see EXAMPLES.md for complete configuration)
Erwartet: cert-manager erholt Zertifikat von Let's Encrypt. TLS-Secret mit gueltigem Zertifikat und privatem Schluessel erstellt. Zertifikat wird vor Ablauf automatisch erneuert.
Bei Fehler: Bei ACME-Challenge-Fehlern DNS auf Ingress-LoadBalancer-IP pruefen. Bei Rate-Limit-Fehlern letsencrypt-staging-Issuer fuer Tests verwenden.
Secret-Rotation mit Versionsverwaltung und Anwendungsneustarts automatisieren.
# Enable automatic Pod restarts on Secret changes with Reloader
kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml
# Annotate Deployment to watch Secretscat <<EOF | kubectl apply -f -
apiVersion: apps/v1
# ... (see EXAMPLES.md for complete configuration)
Rotationsworkflow verifizieren:
# Manually trigger rotation
kubectl create job --from=cronjob/secret-rotation manual-rotation-$(date +%s)
# Watch for Secret update
kubectl get secret myapp-db-secret -w
# Verify Reloader triggered Pod restart
kubectl get events --sort-by='.lastTimestamp' | grep Reloader
# Check new Pods are using updated secret
kubectl get pods -l app=myapp
kubectl exec -it <pod-name> -- env | grep DB_PASSWORD
Erwartet: Reloader ueberwacht Secrets/ConfigMaps und startet Pods bei Aenderungen neu. Secret-Rotation aktualisiert AWS Secrets Manager, External Secrets Operator synchronisiert mit Kubernetes, Reloader loest Rolling Restart aus.
Bei Fehler: Wenn Reloader nicht ausloest, Annotation-Syntax und Reloader-Status mit kubectl get pods -n default -l app=reloader-reloader pruefen.
Secret-Zugriff mit Kubernetes RBAC nach Least-Privilege-Prinzip einschraenken.
# Create namespace for sensitive workloadsapiVersion:v1kind:Namespacemetadata:name:production---# ... (see EXAMPLES.md for complete configuration)
RBAC testen:
# Apply RBAC resources
kubectl apply -f rbac.yaml
# Test as application service account
kubectl auth can-i get secret myapp-db-secret --as=system:serviceaccount:production:myapp -n production
# Should return "yes"# ... (see EXAMPLES.md for complete configuration)
Erwartet: Service-Accounts haben schreibgeschuetzten Zugriff auf spezifische Secrets ueber resourceNames. Entwickler koennen Secrets im Production-Namespace nicht einsehen. Nur secret-admins-Gruppe kann Secrets erstellen/aktualisieren/loeschen.
Bei Fehler: Bei Zugriffsverweigerungsfehlern pruefen, ob RoleBinding-Subjects dem ServiceAccount-Namen und Namespace entsprechen. Fuer zu permissive Rollen Wildcard-Verbs entfernen und resourceNames-Einschraenkung hinzufuegen.
Validierung
Secrets im Ruhezustand in etcd verschluesselt (mit etcdctl oder KMS pruefen)
Sealed Secrets Controller laeuft und oeffentliches Zertifikat abgerufen
External Secrets Operator synchronisiert aus Cloud-Secret-Managern
TLS-Zertifikate von cert-manager ausgestellt und automatisch erneuert
Secret-Rotation automatisiert mit Anwendungsneustarts via Reloader
RBAC-Richtlinien erzwingen Least-Privilege-Zugriff auf Secrets
Keine Klartext-Secrets in Git-Repositories oder Container-Images
Monitoring-Alerts fuer Secret-Synchronisierungsfehler und Ablauf konfiguriert
Haeufige Stolperfallen
Secrets in der Git-Historie: Klartext-Secrets committen und spaeter entfernen loescht sie nicht aus der Git-Historie. git-filter-repo oder BFG verwenden, um Historie neu zu schreiben, kompromittierte Secrets rotieren.
Zu breites RBAC: get secrets fuer alle Secrets im Namespace gewaehren. resourceNames verwenden, um Zugriff auf spezifische Secrets zu beschraenken.
Keine Rotationsstrategie: Secrets werden niemals rotiert, was den Blast Radius eines Kompromisses erhoert. Automatisierte Rotation mit External Secrets Operator oder CronJobs implementieren.
Fehlende Verschluesselung im Ruhezustand: Secrets im Klartext in etcd gespeichert. Verschluesselungs-Provider oder KMS-Integration aktivieren, bevor sensible Daten gespeichert werden.
Anwendungs-Caching von Secrets: App liest Secret einmal beim Start und laedt nie neu. Signal-Behandlung (SIGHUP) oder Datei-Watcher fuer Secret-Dateiiaenderungen implementieren.
External Secrets zu langsame Aktualisierung: Standard-1h-Aktualisierung bedeutet, dass Secret-Aenderungen bis zu einer Stunde brauchen. refreshInterval fuer kritische Secrets verringern, Webhooks fuer sofortige Aktualisierungen verwenden.
Kein Backup des sealed-secrets-Schluessels: Controller-privater Schluessel verloren, alle versiegelten Secrets nicht wiederherstellbar. Sichern mit kubectl get secret -n kube-system sealed-secrets-key -o yaml > backup.yaml und sicher aufbewahren.
Zertifikatserneuerungsfehler: cert-manager kann aufgrund von DNS/Firewall-Aenderungen nicht erneuern. Zertifikatsablauf mit Prometheus-Metriken und Alerts ueberwachen.
Verwandte Skills
deploy-to-kubernetes - Secrets in Deployments und StatefulSets verwenden
