Bewährte Praktiken für die Verwaltung von Geheimnissen und sensiblen Daten in Kubernetes-Clustern

Kubernetes-Geheimnisse sind praktisch, aber sie sind nicht automatisch sicher, nur weil das Objekt Secret heißt. Wenn Ihre RBAC zu weit gefasst ist oder etcd nicht verschlüsselt ist, kann ein durchgesickertes Token Datenbankpasswörter, API-Schlüssel und private Zertifikate in Ihrem gesamten Cluster offenlegen.

Verwenden Sie Kubernetes-Geheimnisse als eine Schicht und fügen Sie dann Verschlüsselung, Zugriffskontrolle, sicherere Injektionsmuster und externe Geheimnisspeicher hinzu, wo das Risiko dies rechtfertigt.

Kubernetes-Geheimnisse verstehen: Der Standardmechanismus

Kubernetes führt das Secret-Objekt ein, das speziell für die Aufbewahrung sensibler Informationen entwickelt wurde. Obwohl es nützlich ist, ist es entscheidend, seine Einschränkungen und das Standardverhalten in Bezug auf Sicherheit zu verstehen.

Standardverhalten und Einschränkungen

Standardmäßig sind Kubernetes-Geheimnisse nicht im Ruhezustand verschlüsselt in etcd, dem Backend-Speicher des Clusters für alle Konfigurationsdaten. Sie sind lediglich Base64-kodiert, was keine tatsächliche Verschlüsselung bietet. Jeder mit Zugriff auf den etcd-Datenspeicher (z. B. Cluster-Administratoren, kompromittierte Knoten) kann diese Werte leicht dekodieren.

Warnung: Verlassen Sie sich niemals ausschließlich auf das standardmäßige Kubernetes-Secret-Objekt für hochsensible Daten, ohne Verschlüsselungsmaßnahmen anzuwenden.

Base64-Kodierung vs. Verschlüsselung

Es ist ein häufiges Missverständnis, dass Base64-Kodierung Sicherheit bietet. Base64 ist ein Kodierungsschema, kein Verschlüsselungsschema. Es ist leicht umkehrbar:

# Beispiel für das Dekodieren eines Kubernetes-Secret-Werts
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# Ausgabe: super-secret

Schicht 1: Sicherung von Geheimnissen im Ruhezustand (etcd-Verschlüsselung)

Der grundlegendste Schritt zur Sicherung von Geheimnissen besteht darin, sicherzustellen, dass sie auf der Speicherebene (etcd) verschlüsselt sind. Dies schützt Daten, selbst wenn die zugrunde liegende Datenbank direkt zugegriffen wird.

Aktivieren der Verschlüsselung im Ruhezustand

Die Verschlüsselung im Ruhezustand wird über den Kubernetes-API-Server mithilfe eines EncryptionConfiguration-Objekts konfiguriert. Diese Konfiguration gibt an, welche Anbieter zur Verschlüsselung verschiedener Arten von in etcd gespeicherten Daten verwendet werden sollen, einschließlich secrets.

Schlüsselkomponenten der Verschlüsselungskonfiguration:

1. kind: EncryptionConfiguration: Deklariert den Ressourcentyp.
2. resources: Gibt an, welche API-Ressourcen verschlüsselt werden sollen.
3. providers: Definiert den Verschlüsselungsmechanismus. Häufige Anbieter sind aescbc, aesgcm und KMS-Anbieter (wie AWS KMS oder GCP KMS).

Bewährte Praxis: Verwenden Sie einen KMS-Anbieter, wenn Ihre Plattform dies unterstützt. Wenn Sie lokale Schlüssel verwenden, verwalten Sie die Schlüsselrotation sorgfältig und behalten Sie alte Schlüssel, bis vorhandene Daten erneut verschlüsselt wurden.

Schicht 2: Sicherung von Geheimnissen während der Übertragung und bei der Verwendung

Während die etcd-Verschlüsselung das Problem "im Ruhezustand" löst, werden Geheimnisse vom Kubelet entschlüsselt, wenn sie in einen Pod eingebunden werden. Wir müssen kontrollieren, wie und wo diese Geheimnisse erscheinen.

Strategie 1: Volume-Mounting von Geheimnissen

Die Standardmethode zum Injizieren von Secret-Daten in einen Container besteht darin, sie als Volume zu mounten (was oft zu einer Datei im Dateisystem des Containers führt).

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

Sicherheitsaspekt: Gemountete Secret-Volumes werden auf Linux-Knoten normalerweise durch tmpfs unterstützt, aber die Werte sind immer noch für den Containerprozess und für jeden mit ausreichendem Knoten- oder Pod-Zugriff sichtbar. Verwenden Sie readOnly: true, vermeiden Sie das Ausgeben von Umgebungs- oder Konfigurationsdateien in Protokolle und beschränken Sie den Shell-Zugriff auf Produktions-Pods.

Strategie 2: Umgebungsvariablen (für hohe Sensitivität nicht empfohlen)

Obwohl praktisch, wird die Verwendung von Umgebungsvariablen, die aus Geheimnissen stammen, für hochwertige Geheimnisse im Allgemeinen nicht empfohlen. Umgebungsvariablen können leicht durch Folgendes durchsickern:

• Containerprotokolle, die von schlecht konfigurierten Anwendungen generiert werden.
• Lesen von /proc/1/environ innerhalb des Containers oder anderer privilegierter Container.
• Container-Inspektionswerkzeuge.

Verwenden Sie Umgebungsvariablen nur für Konfigurationsdaten mit geringer Sensitivität, wenn Sie sie verwenden müssen.

Schicht 3: Erweiterte Verwaltung mit externen Geheimnisspeichern

Das sicherste Muster besteht darin, sensible Daten vollständig außerhalb der Kubernetes-Steuerungsebene (etcd) zu halten und sie zur Laufzeit mithilfe spezieller Werkzeuge dynamisch abzurufen.

Verwendung externer Geheimnis-Operatoren

Externe Geheimnis-Operatoren überbrücken die Lücke zwischen einem sicher in einem dedizierten Tresor (wie HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) gespeicherten Geheimnis und dem nativen Kubernetes-Secret-Objekt.

1. Speicher: Das eigentliche Geheimnis lebt nur im externen Tresor.
2. Synchronisieren/Injizieren: Ein Operator überwacht eine benutzerdefinierte Ressource (wie ExternalSecret) und ruft die Daten aus dem Tresor ab.
3. Erstellung: Der Operator erstellt dann lokal ein standardmäßiges Kubernetes Secret-Objekt, das dann in die Pods eingebunden werden kann.

Vorteil: Die Quelle der Wahrheit bleibt außerhalb des Clusters, was Rotation und Prüfbarkeit verbessert. Das synchronisierte Kubernetes-Secret existiert jedoch weiterhin im Cluster, sodass Sie weiterhin RBAC, etcd-Verschlüsselung und Namespace-Isolierung benötigen.

Verwendung des Secrets Store CSI-Treibers

Für Anwendungen, die einen direkten, flüchtigen Zugriff benötigen, ohne das Geheimnis lokal in etcd zu speichern, ist der Secrets Store CSI-Treiber die überlegene Wahl.

• Der Treiber nutzt einen Anbieter (z. B. Vault-Anbieter, Azure-Anbieter).
• Er mountet das Geheimnis direkt aus dem externen Speicher in das Dateisystem des Pods als temporäres Volume, wodurch vermieden wird, die Geheimnisdaten jemals in etcd zu schreiben.

Dies bietet das höchste Sicherheitsniveau, indem das Geheimnis vollständig aus der etcd-Datenbank entfernt wird.

Betriebliche bewährte Praktiken für die Geheimnisverwaltung

Über die technischen Speichermechanismen hinaus ist betriebliche Hygiene entscheidend für die Aufrechterhaltung einer sicheren Haltung.

1. Prinzip der geringsten Privilegien (PoLP)

Stellen Sie sicher, dass das einem Pod zugeordnete Dienstkonto nur Berechtigungen hat, um das spezifische Geheimnis zu lesen, das es benötigt, und keine anderen. Verwenden Sie die rollenbasierte Zugriffskontrolle (RBAC), um Berechtigungen eng zu begrenzen.

2. Geheimnisse häufig rotieren

Implementieren Sie automatisierte Rotationspläne für alle Anmeldeinformationen. Langlebige Geheimnisse vergrößern das Zeitfenster für eine Kompromittierung. Werkzeuge, die in externe Tresore integriert sind, übernehmen diese Rotation oft automatisch.

3. Zugriff prüfen und überwachen

Konfigurieren Sie die Audit-Protokollierung, um zu verfolgen, wer Secret-Objekte liest oder ändert. Werkzeuge, die in externe Tresore integriert sind (wie Vault-Agenten oder CSI-Treiber), sollten ebenfalls Zugriffsversuche auf den externen Speicher protokollieren.

4. Geheimnisse niemals in Git committen

Dies ist eine grundlegende Regel. Speichern Sie niemals rohe oder sogar Base64-kodierte Geheimnisse in Git-Repositorys, selbst in privaten. Verwenden Sie Werkzeuge wie git-secrets oder Konfigurationsmanagement-Templating-Werkzeuge (wie Helm oder Kustomize) in Kombination mit externen Geheimnisinjektionsmechanismen, um Bereitstellungsmanifeste zu verwalten.

Beispiel mit Kustomize (Externe Referenz):

Bei Verwendung von Templating könnten Sie Platzhalter in Ihren Manifestdateien verwenden und sich auf einen Build-Schritt oder eine CI/CD-Pipeline verlassen, um die tatsächlichen Geheimniswerte, die sicher aus einem Tresor abgerufen wurden, vor dem Anwenden des YAML auf den Cluster zu injizieren.

Vergleich der Verwaltungsstrategien

Strategie	Sicherheitsstufe	etcd-Exposition?	Komplexität	Am besten geeignet für
Standard-K8s-Secret (keine etcd-Verschlüsselung)	Sehr niedrig	Ja (Klartext)	Niedrig	Nur temporäre Tests
K8s-Secret mit etcd-Verschlüsselung	Mittel	Ja (Verschlüsselt)	Mittel	Allgemeine Konfigurationsdaten
Externer Geheimnis-Operator	Hoch	Ja (Operator-verwaltetes Secret)	Hoch	Standardisierung der Geheimnisverwaltung
Secrets Store CSI-Treiber	Am höchsten	Nein (Direkter Mount)	Hoch	Hochsensible Anmeldeinformationen und Token

Beginnen Sie mit der Aktivierung der etcd-Verschlüsselung und der Verschärfung von RBAC. Entscheiden Sie dann, ob jede Arbeitslast synchronisierte Geheimnisse, direkte CSI-Mounts oder dynamische Anmeldeinformationen aus einem externen Tresor verwenden kann. Das beste Setup ist dasjenige, das einschränkt, wer das Geheimnis lesen kann, wo es gespeichert ist und wie lange es nach der Offenlegung nützlich bleibt.