Beste Kubernetes-Secrets-Management-Tools im Jahr 2026: Vault, ESO, Sealed Secrets und mehr

Jeder Kubernetes-Cluster wird mit einem integrierten „Secret“-Objekt geliefert. Es sieht nach Sicherheit aus. Es fühlt sich wie Sicherheit an. Es ist keine Sicherheit.

Ein Kubernetes-Geheimnis ist standardmäßig nur eine Base64-codierte Zeichenfolge, die in etcd gespeichert ist – lesbar für jeden mit Cluster-Zugriff und einfach mit einem Einzeiler dekodierbar: „echo „c2VjcmV0“ |“. base64 -d`. Sofern Sie die Verschlüsselung im Ruhezustand nicht explizit aktiviert haben (was bei den meisten Teams nicht der Fall ist), liegen Ihre Datenbankkennwörter, API-Tokens und privaten TLS-Schlüssel unverschlüsselt im Datenspeicher der Steuerungsebene Ihres Clusters. Übertragen Sie ein Kubernetes-Manifest, das ein „Geheimnis“ enthält, an Git, und diese Anmeldeinformationen verbleiben für immer im Verlauf Ihres Repositorys.

Dies ist das Problem, zu dessen Lösung eine neue Generation von Secrets-Management-Tools auf den Markt gekommen ist – und im Jahr 2026 ist das Ökosystem deutlich ausgereifter geworden. Dieser Leitfaden behandelt die sechs wichtigsten Tools zum Verwalten von Geheimnissen in Kubernetes-Umgebungen: was sie tun, was sie nicht tun und welches zum Reifegrad Ihres Teams passt.

Verwandte Lektüre: Wenn Sie befürchten, dass Geheimnisse durch Ihre CI/CD-Pipeline dringen, lesen Sie unsere Zusammenfassung der besten CI/CD-Pipeline-Tools. Weitere Informationen zur Containersicherheit finden Sie in unserem Leitfaden zu Tools zum Scannen von Sicherheitslücken.

Warum Kubernetes-Standardgeheimnisse zu kurz kommen

Bevor Sie sich mit den Tools befassen, sollten Sie sich genau darüber im Klaren sein, was den Kubernetes-Geheimnissen fehlt – denn wenn Sie die Lücke kennen, können Sie die richtige Lösung auswählen.

Standardmäßig keine Verschlüsselung im Ruhezustand. etcd speichert Kubernetes-Geheimnisse als Base64, nicht verschlüsselt. Das Aktivieren der Verschlüsselung im Ruhezustand ist ein Konfigurationsschritt auf Clusterebene, den verwaltete Kubernetes-Anbieter (EKS, GKE, AKE) unterschiedlich handhaben und der von vielen selbstverwalteten Clustern vollständig übersprungen wird.

Keine Secret-Rotation. Es gibt keinen integrierten Mechanismus, mit dem ein Kubernetes-Secret erkennen kann, dass sich seine Backing-Anmeldeinformationen geändert haben. Sie rotieren ein Datenbankkennwort extern und Ihre Pods verwenden weiterhin das alte, bis Sie das Secret manuell aktualisieren und die betroffenen Pods neu starten.

Kein Audit-Protokoll für geheimen Zugriff. Die standardmäßige Kubernetes-Audit-Protokollierung zeichnet geheime Objektänderungen auf, aber die meisten Konfigurationen protokollieren keine einzelnen Lesevorgänge – das heißt, Sie können nicht antworten: „Welcher Dienst hat wann auf dieses Token zugegriffen?“

Von Natur aus Git-feindlich. Der Standardratschlag lautet: „Übertrage niemals Geheimnisse an Git.“ Aber in einer GitOps-Welt, in der alles als Code das Ziel ist, ist dies eine schmerzhafte Ausnahme, die man beibehalten muss.

RBAC als stumpfes Instrument. Mit Kubernetes RBAC können Sie den Zugriff auf Secret-Objekte auf Namespace-Ebene gewähren oder verweigern. Es kann nicht ausgedrückt werden „Dienst A kann Geheimnis X lesen, aber nicht Geheimnis Y“ oder „Dieses Geheimnis läuft in 24 Stunden ab.“

Das sind keine Gründe, Kubernetes aufzugeben – es sind vielmehr Gründe, zusätzlich dedizierte Secrets-Management-Tools zu verwenden.

TL;DR – Funktionsvergleich

⚠️ = erfordert zusätzliche Komponenten

1. HashiCorp Vault – Der Goldstandard für Unternehmensgeheimnisse

HashiCorp Vault ist der Maßstab, an dem jedes andere Secrets-Management-Tool gemessen wird. Es hat sich seit fast einem Jahrzehnt in Unternehmensumgebungen bewährt und sein Funktionsumfang spiegelt diese Tiefe wider.

Die Kernfunktion von Vault sind dynamische Geheimnisse – Anmeldeinformationen, die bei Bedarf generiert werden und automatisch ablaufen. Anstatt ein statisches PostgreSQL-Passwort zu speichern, generiert Vault für jeden anfordernden Dienst ein eindeutiges Benutzername/Passwort-Paar, das für einen konfigurierbaren Lease-Zeitraum (z. B. eine Stunde) gültig ist. Wenn der Mietvertrag abläuft, wird der Berechtigungsnachweis widerrufen. Dies eliminiert die Ausbreitung ganzer Klassen von Anmeldeinformationen und erleichtert die Eindämmung von Sicherheitsverletzungen erheblich.

Für Kubernetes sind der Vault Agent Injector oder der Vault Secrets Operator die Integrationspfade. Der Injektor wird als mutierender Webhook ausgeführt, der automatisch einen Vault-Agenten in Ihre Pods einfügt, der sich mithilfe des Kubernetes-Dienstkontos des Pods bei Vault authentifiziert und Geheimnisse auf ein gemeinsam genutztes In-Memory-Volume schreibt. Der Vault Secrets Operator (VSO), der neuere Ansatz, synchronisiert Vault-Geheimnisse mit nativen Kubernetes Secret-Objekten – was den Betreibern vertrauter ist, auf Kosten von Geheimnissen, die kurzzeitig in etcd vorhanden sind.

Die geheimen Engines von Vault decken ein beeindruckendes Spektrum ab:

• Datenbankanmeldeinformationen (PostgreSQL, MySQL, MongoDB und mehr) – Dynamische AWS-, GCP- und Azure-Anmeldeinformationen
• Generierung von PKI- und TLS-Zertifikaten
• Signieren von SSH-Zertifikaten
• Kubernetes-Dienstkonto-Tokens

Was Vault gut macht: Dynamische Anmeldeinformationen, differenzierte Zugriffsrichtlinien, ein umfassendes Audit-Protokoll und ein ausgereiftes Plugin-Ökosystem. Wenn Sie eine vertrauliche Verwaltung auf Compliance-Niveau mit vollständiger Übersicht darüber benötigen, wer wann auf was zugegriffen hat, ist Vault oft die einzig sinnvolle Option.

Worauf Sie achten sollten: Vault weist eine betriebliche Komplexität auf. Die Ausführung im Hochverfügbarkeitsmodus erfordert sorgfältige Aufmerksamkeit für Speicher-Backends (Raft ist jetzt die empfohlene Wahl), Entsiegelungsverfahren und Upgrade-Pfade. Die Lernkurve ist real. Budget für die Entwicklungszeit der Plattform.

Preise: Die Open-Source-Version ist kostenlos und deckt die meisten Anforderungen ab. HashiCorp Cloud Platform (HCP) Vault ist das verwaltete Angebot, dessen Preise auf Cluster-Stunden und geheimen Vorgängen basieren. Die BSL-Lizenzänderung ab 2023 führte zum OpenTofu-Fork für Terraform, aber das Fork-Äquivalent von Vault (OpenBao) befindet sich noch in der Reifephase.

📚 Empfohlene Lektüre: Hacking Kubernetes von Andrew Martin und Michael Hausenblas – hervorragende Berichterstattung über Kubernetes-Angriffsflächen einschließlich geheimer Exfiltrationsszenarien.

2. External Secrets Operator (ESO) – Die K8s-Native-Integrationsschicht

External Secrets Operator vertritt eine grundlegend andere architektonische Haltung: Anstatt selbst ein Secrets Store zu sein, ist es eine Brücke zwischen Kubernetes und dem externen Store, den Sie bereits haben. ESO synchronisiert Geheimnisse von AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler und einer wachsenden Liste anderer Backends in native Kubernetes Secret-Objekte.

Die Kernabstraktion ist die benutzerdefinierte Ressource „ExternalSecret“:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

ESO überwacht diese Ressource, ruft das Geheimnis vom AWS Secrets Manager (oder wo auch immer) ab und erstellt ein Standard-Kubernetes-Geheimnis. Ihre Anwendung liest „db-creds“ wie jedes andere Kubernetes-Geheimnis – es sind keine Codeänderungen erforderlich. Wenn „refreshInterval“ aktiviert ist, ruft ESO das Secret erneut ab und aktualisiert es automatisch.

Warum ESO im Jahr 2026 so beliebt ist: Es passt gut zu bestehenden Investitionen. Ihre Organisation verfügt bereits über AWS Secrets Manager (oder Vault oder GCP Secret Manager) – ESO macht diese Geheimnisse einfach in Kubernetes nutzbar, ohne Ihren Anwendungscode oder Ihre bestehenden Secret-Rotations-Workflows zu ändern.

ESO oder Vault Secrets Operator? Wenn Sie Vault ausführen, verfügt das VSO über eine engere Vault-spezifische Integration (dynamische Vault-Geheimnisse, Vault PKI). Wenn Sie den nativen Secret Store eines Cloud-Anbieters nutzen, ist ESO die sauberere Wahl. Viele Teams nutzen beides – ESO für in der Cloud gespeicherte statische Geheimnisse und VSO für über Vault verwaltete dynamische Anmeldeinformationen.

Preise: ESO ist kostenlos und Open Source (Apache 2.0) und wird von einem CNCF-Sandbox-Projekt mit starker Community-Unterstützung verwaltet.

3. Versiegelte Geheimnisse – GitOps-freundliche verschlüsselte Geheimnisse

Sealed Secrets von Bitnami löst ein spezifisches Problem: Wie speichert man Kubernetes Secret-Manifeste in Git, ohne den eigentlichen Klartext zu speichern? Die Antwort ist asymmetrische Verschlüsselung.

Der Sealed Secrets-Controller wird in Ihrem Cluster ausgeführt und enthält einen privaten Schlüssel. Die „kubeseal“-CLI verschlüsselt ein Kubernetes-Secret-Manifest mit dem öffentlichen Schlüssel des Clusters und erstellt so ein „SealedSecret“-CRD. Dieses verschlüsselte Manifest kann sicher an Git übergeben werden – nur der private Schlüssel des Clusters kann es entschlüsseln, und es kann nur in diesem bestimmten Cluster entschlüsselt werden (standardmäßig ist der Chiffretext an Namespace + Name gebunden).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Wenn Sie das „SealedSecret“ auf den Cluster anwenden, entschlüsselt der Controller es und erstellt das entsprechende „Secret“-Objekt.

Was Sealed Secrets gut macht: GitOps-Workflows. Wenn Sie Argo CD oder Flux verwenden und möchten, dass jede Clusterressource (einschließlich Geheimnisse) deklarativ in Git gespeichert wird, passt Sealed Secrets perfekt zu diesem Modell. Es erfordert keinerlei externe Abhängigkeiten über den In-Cluster-Controller hinaus.

Was es nicht tut: Rotation, dynamische Anmeldeinformationen oder Audit-Logging über Standard-Kubernetes-Ereignisse hinaus. Sealed Secrets ist eine Git-Speicherlösung, keine vollständige Secrets-Management-Plattform. Wenn sich Ihr Passwort ändert, müssen Sie es erneut verschlüsseln und erneut festlegen.

Die Sicherung des privaten Schlüssels ist von entscheidender Bedeutung. Wenn Sie den privaten Schlüssel des Controllers verlieren, verlieren Sie die Möglichkeit, Ihre versiegelten Geheimnisse zu entschlüsseln. Sichern Sie das Geheimnis „sealed-secrets-key“ an einem separaten, sicheren Ort.

Preise: Völlig kostenlos und Open Source (Apache 2.0).

4. AWS Secrets Manager mit Kubernetes

Wenn Ihre Workloads hauptsächlich auf EKS laufen (oder stark mit AWS-Diensten verbunden sind), ist AWS Secrets Manager in Kombination mit dem Secrets Store CSI Driver oder External Secrets Operator die natürliche Lösung. Sie bewahren Geheimnisse im verwalteten, verschlüsselten und protokollierten Speicher von AWS auf und übertragen sie bei Bedarf in Kubernetes.

Der Secrets Store CSI Driver (SSCSID) ist der von CNCF verwaltete Ansatz: Geheimnisse werden über ein CSI-Volume direkt als Dateien in Pods gemountet und niemals als Kubernetes Secret-Objekte in etcd geschrieben. Dies ist der Pfad mit der höchsten Sicherheit – Geheimnisse sind im Pod-Speicher vorhanden, jedoch nicht im Kubernetes Secret Store.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

Zu den nativen Funktionen von AWS Secrets Manager gehören die automatische Rotation für unterstützte Dienste (RDS, Redshift, DocumentDB und über Lambda für benutzerdefinierte Rotation), kontoübergreifender Zugriff und eine umfassende CloudTrail-Integration für Compliance-Audit-Trails.

Kostenüberlegung: AWS Secrets Manager berechnet pro Geheimnis, pro Monat und pro API-Aufruf. Bei großen Flotten mit vielen kleinen Geheimnissen können sich die Kosten summieren. In unserem Leitfaden zur Cloud-Kostenoptimierung finden Sie Strategien zur Verwaltung geheimer AWS-Ausgaben.

Best für: EKS-native Teams, die bereits in das AWS-Ökosystem investiert haben und eine enge IAM-Integration und native RDS-Anmeldeinformationsrotation wünschen.

5. Doppler – Entwickler-erste SaaS-Secrets-Plattform

Doppler verfolgt einen SaaS-First-Ansatz, bei dem die Entwicklererfahrung Vorrang vor der betrieblichen Komplexität hat. Sie definieren Secrets in der Benutzeroberfläche von Doppler (oder über CLI/API), organisieren sie nach Umgebung (Entwicklung, Staging, Produktion) und der Doppler Kubernetes-Operator synchronisiert sie automatisch mit Kubernetes Secrets.

Der Operator fragt Doppler nach Änderungen ab und aktualisiert das entsprechende Kubernetes-Geheimnis, wobei er optional Pod-Neustarts auslöst, wenn sich Geheimnisse ändern. Das Setup ist eine einzelne Helm-Chart-Installation:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Wo Doppler glänzt: Lokale Entwicklung und CI/CD-Integration neben Kubernetes. Die Doppler-CLI ersetzt Umgebungsdateien vollständig („doppler run – your-command“) und stellt dieselben Geheimnisse in lokalen, CI- und Produktionsumgebungen bereit. Für CI/CD-Pipelines machen die nativen Integrationen von Doppler mit GitHub Actions, CircleCI und anderen das Kopieren von Geheimnissen in Pipeline-Umgebungsvariablen überflüssig.

Was Doppler nicht abdeckt: Dynamische Datenbankanmeldeinformationen. Doppler ist ein statischer Geheimspeicher mit Versionsverlauf und Prüfprotokollierung – es handelt sich nicht um eine Geheimgenerierungs-Engine wie Vault.

Preise: Doppler bietet eine kostenlose Stufe für kleine Teams an. Bezahlte Pläne beinhalten SSO, Zugriffsanfragen und Compliance-Funktionen. Überprüfen Sie die Preisseite von Doppler auf aktuelle Stufen (Preisänderungen; überprüfen Sie diese vor der Budgetierung).

6. Infisical – Open-Source-Vault-Alternative

Infisical ist der stärkste Open-Source-Herausforderer des Vault/Doppler-Duopols. Es bietet eine Web-Benutzeroberfläche, CLI, SDKs und einen Kubernetes-Operator – kann selbst gehostet oder als Cloud-Dienst genutzt werden.

Infisical fügte im Jahr 2024 die Unterstützung dynamischer Geheimnisse hinzu und zielt auf die Generierung von Datenbankanmeldeinformationen ab, ähnlich wie die Engine für Datenbankgeheimnisse von Vault. Der Infisical Kubernetes-Operator synchronisiert „InfisicalSecret“-CRDs mit konfigurierbaren Aktualisierungsintervallen mit nativen Kubernetes-Geheimnissen.

Für Teams, die UX auf SaaS-Ebene wünschen (Web-Dashboard, Zugriffsanfrage-Workflows, Audit-Protokolle), aber aufgrund von Compliance-Anforderungen kein externes SaaS verwenden können, ist das selbst gehostete Infisical überzeugend. Es ist wesentlich einfacher zu bedienen als Vault und bietet ein entwicklerfreundlicheres Onboarding-Erlebnis.

Preise: Der Open-Source-Kern ist kostenlos. Die in der Cloud gehostete Version verfügt über ein kostenloses Kontingent und kostenpflichtige Pläne für erweiterte Funktionen. Für Compliance-intensive Umgebungen ist eine selbstgehostete Unternehmenslizenz verfügbar.

📚 Für einen tieferen Einblick in die Sicherheitsarchitektur von Kubernetes: Kubernetes Security and Observability auf Amazon deckt Geheimnisse, RBAC, Netzwerkrichtlinien und Laufzeitsicherheit in einem zusammenhängenden Framework ab.

Implementierungstipps

Beginnen Sie mit der Verschlüsselung im Ruhezustand. Bevor Sie zusätzliche Tools hinzufügen, aktivieren Sie die Kubernetes-ETCD-Verschlüsselung im Ruhezustand. Bei verwalteten Clustern ist dies häufig ein einzelnes Kontrollkästchen. Befolgen Sie für selbstverwaltete Cluster den offiziellen Leitfaden. Dadurch wird Ihr grundlegender Sicherheitsstatus sofort erhöht.

Übernehmen Sie RBAC mit den geringsten Berechtigungen für Secrets. Überwachen Sie, welche Dienstkonten über „Get“, „List“- oder „Watch“-Berechtigungen für Secret-Objekte verfügen. Standarddienstkonten in vielen Helm-Charts sind überdimensioniert. Ziehen Sie den RBAC fest, bevor Sie ihn zu einem externen Lager drehen.

Planen Sie Ihre Namenskonventionen für Geheimnisse frühzeitig. Geheimnisse verbreiten sich schnell. Eine konsistente Hierarchie („{env}/{service}/{credential-type}“) macht Automatisierung, RBAC-Richtlinien und Rotationsworkflows über alle Tools hinweg erheblich einfacher.

Lassen Sie geheime Rotationstests nicht aus. Welches Werkzeug Sie auch wählen, führen Sie eine Rotationsübung durch, bevor Sie sie benötigen. Stellen Sie sicher, dass Ihre Anwendung neue Anmeldeinformationen ohne Ausfallzeiten erhält. Dynamische Geheimnisse mit Vault oder ESO machen dies wesentlich einfacher als manuell aktualisierte statische Geheimnisse.

Überwachen Sie die Ausbreitung von Geheimnissen. Wenn Ihre Plattform wächst, sammeln sich Geheimnisse an. Integrieren Sie Secrets-Management-Reporting in Ihre Plattform-Engineering-Dashboards. In unserem Kubernetes-Überwachungstools-Leitfaden finden Sie Observability-Tools, mit denen geheime Zugriffsmuster verfolgt werden können.

Welches Tool für welches Team?

Kleines Team, Cloud-nativ (AWS/GCP/Azure): Beginnen Sie mit dem External Secrets Operator, der eine Verbindung zum nativen Secret Store Ihres Cloud-Anbieters herstellt. Minimaler Betriebsaufwand, solide Audit-Integration, kostenlos.

GitOps-First-Team (Argo CD / Flux): Versiegelte Geheimnisse für die in GitOps gespeicherte Konfiguration, kombiniert mit ESO für vertrauliche Laufzeitanmeldeinformationen, die in Git nicht einmal verschlüsselt sein sollten.

Unternehmen mit Compliance-Anforderungen (SOC 2, PCI, HIPAA): HashiCorp Vault – entweder selbst gehosteter Raft-Cluster oder HCP Vault verwaltet. Das Prüfprotokoll, die dynamischen Anmeldeinformationen und die fein abgestimmte Richtlinien-Engine lassen sich anderswo nur schwer replizieren.

Entwicklererfahrungsorientierte, gemischte Umgebung (K8s + lokal + CI/CD): Doppler für den einheitlichen DX in allen Umgebungen oder Infisical selbst gehostet, wenn die Datenresidenz wichtig ist.

Großes Plattformteam, das Multi-Cluster-Umgebungen verwaltet: External Secrets Operator als K8s-seitige Abstraktionsschicht, unterstützt durch Vault oder einen Cloud-nativen Store. Die Zentralisierung der Quelle der Wahrheit in einem Geschäft bei gleichzeitiger Nutzung von ESO als universellem Adapter über Cluster hinweg ist im Jahr 2026 ein bewährtes Muster.

Verwandt: Informationen zu den Sicherheitsrisiken, die durch KI-Codierungstools in Ihren Kubernetes-Manifesten und CI/CD-Pipelines entstehen, finden Sie in unserem Leitfaden zu Vibe-Coding-Sicherheitsrisiken im Jahr 2026.

FAQ

Sind Kubernetes-Geheimnisse standardmäßig verschlüsselt?

Nein. Kubernetes Secrets sind standardmäßig Base64-kodiert – Kodierung, keine Verschlüsselung. Die Daten werden unverschlüsselt in etcd gespeichert, es sei denn, Sie aktivieren ausdrücklich die Verschlüsselung im Ruhezustand. Überprüfen Sie immer Ihre Clusterkonfiguration und ziehen Sie externe Tools zur Geheimnisverwaltung für Produktions-Workloads in Betracht.

Was ist der Unterschied zwischen Sealed Secrets und External Secrets Operator?

Sealed Secrets verschlüsselt Secret-Manifeste für eine sichere Git-Speicherung – es handelt sich um eine GitOps-Lösung. Der Operator für externe Geheimnisse ruft Live-Geheimnisse aus externen Speichern (Vault, AWS Secrets Manager usw.) ab und erstellt daraus native Kubernetes-Geheimnisse. Sie lösen unterschiedliche Probleme und werden oft zusammen verwendet.

Was sind dynamische Geheimnisse und warum sind sie wichtig?

Bei dynamischen Geheimnissen handelt es sich um Anmeldeinformationen, die bei Bedarf generiert werden und automatisch ablaufen – und nicht um statische Passwörter, die auf unbestimmte Zeit gespeichert werden. HashiCorp Vault ist die Hauptquelle dynamischer Geheimnisse für Kubernetes. Wenn ein dynamischer Berechtigungsnachweis kompromittiert wird, läuft er nach eigenem Zeitplan ab. Dadurch wird der Explosionsradius des Einbruchs im Vergleich zu langlebigen statischen Geheimnissen drastisch begrenzt.

Sollte ich Doppler oder HashiCorp Vault für Kubernetes verwenden?

Doppler überzeugt durch Entwicklererfahrung und schnelle Einführung. Vault überzeugt in puncto Unternehmens-Compliance – dynamische Anmeldeinformationen, detaillierte Prüfprotokolle und differenzierte Richtlinien. Für kleine bis mittelgroße Teams ist Doppler oft der schnellere Weg. Für SOC 2-, PCI DSS- oder HIPAA-Umgebungen ist Vault in der Regel die vertretbarere Wahl.

Wie verhindere ich, dass Geheimnisse in Containerprotokolle gelangen?

Hängen Sie Geheimnisse als Dateien und nicht als Umgebungsvariablen ein (Umgebungsvariablen können über „/proc“ und Debug-Endpunkte verfügbar gemacht werden). Verwenden Sie den Secrets Store CSI-Treiber, um etcd vollständig zu umgehen. Scannen Sie Ihre CI/CD-Pipeline nach versehentlichen geheimen Commits mit Tools wie dem Secret Scanner von Trivy – Einzelheiten zur Einrichtung finden Sie in unserem Leitfaden zu Tools zum Scannen von Sicherheitslücken.

Was ist das beste Secrets-Management-Tool für ein kleines Kubernetes-Team?

Beginnen Sie mit dem External Secrets Operator, der vom nativen Secret Store Ihres Cloud-Anbieters unterstützt wird. Minimaler Betriebsaufwand, solide Audit-Protokollierung, kostenlos. Fügen Sie die kostenlose Stufe von Doppler hinzu, wenn Sie auch ein einheitliches Entwicklungs-/CI-/Produktionsgeheimniserlebnis wünschen.

Wie integriere ich AWS Secrets Manager mit Kubernetes?

Verwenden Sie den External Secrets Operator mit einem ClusterSecretStore, der auf AWS Secrets Manager verweist. Verwenden Sie auf EKS IRSA (IAM Roles for Service Accounts) für die IAM-Authentifizierung auf Pod-Ebene – keine statischen Anmeldeinformationen erforderlich. Verwenden Sie auf Nicht-EKS-Clustern einen IAM-Benutzer mit „secretsmanager:GetSecretValue“, der auf Ihre spezifischen geheimen ARNs beschränkt ist.