Hör auf, Geheimnisse in CI-Variablen zu stecken.

Fragen Sie ein Team, wo ihre Geheimnisse sind, und die ehrliche Antwort ist oft "überall". Einige in CI-Variablen. Einige in einem .env Die Datei, die herumgereicht wird. Einige in Kubernetes-Geheimnissen, die von Hand geschaffen wurden. Ein paar in einem Passwortmanager. Mindestens eine in der Geschichte eines Git-Repositories, von vor drei Jahren.

Geheimnisse sind eines der häufigsten Sicherheitsprobleme, die ich sehe, und eines der einfachsten zu beheben.

Wo Geheimnisse durchsickern

• Git-Geschichte. Einmal begangen, später gelöscht, immer noch da, es sei denn, die Geschichte wird umgeschrieben.
• Die Informantenprotokolle. Ein Debug echo, ein verbosster Befehl, eine kompromittierte Aktion Druck Umgebungsvariablen.
• Variablen der CI mit breitem Zugriff: Jeder, der einen Workflow bearbeiten kann, kann ihn oft lesen.
• Geheimnisse von Kubernetes in einfacher YAML in Git. Base64 ist keine Verschlüsselung.
• Terraformzustand Datenbankpasswörter enthalten.
• Chat und Tickets. "Hier ist das Passwort, löschen Sie diese Nachricht danach".

Der gemeinsame Faden: Geheimnisse werden an viele Orte kopiert, und jede Kopie ist ein Ort, von dem sie durchsickern können.

Ziel: Eine einzige Quelle der Wahrheit

Der bessere Ansatz: Geheimnisse geheim halten ein zentrales Geheimgeschäft, und jeder Verbraucher (Apps, Pipelines, Menschen) sie von dort mit seiner eigenen Identität holen, nur wenn nötig. Idealerweise sind Geheimnisse kurzlebig oder werden automatisch gedreht, sodass ein Leck schnell abläuft.

Die verglichenen Optionen

HashiCorp-Sicherhaus ist die bekannteste. Es speichert Geheimnisse, aber erzeugt sie auch dynamisch: Datenbank-Zugriffsnummern, die auf Anfrage erstellt werden, Cloud-Zugriffsdaten, die nach einer Stunde ablaufen, Zertifikate aus seinem eigenen PKI. Sehr leistungsfähig und eine echte Arbeit, um gut zu laufen (hohe Verfügbarkeit, Entsiegelung, Upgrades). Seit 2023 steht es unter der Business Source License.

OpenBao ist ein ist die Community-Fork von Vault von vor der Lizenzänderung, jetzt unter der Linux Foundation. API-kompatibel mit Vault für die meisten Anwendungsfälle, Open-Source-lizenziert und entwickelt eigene Funktionen.

Cloud-Geheimnismanager: AWS Geheimnismanager, Azure Key Vault, Google Geheimnis Manager. Vollständig verwaltet, integriert mit Cloud IAM, einfach zu starten. Weniger flexibel als Vault für dynamische Geheimnisse in vielen Systemen, aber perfekt genug für viele Teams.

Verschlüsselte Dateien in Git: SOPS (mit Alter oder einem Cloud KMS) verschlüsselt Werte in YAML- oder JSON-Dateien, so dass Sie sie sicher verpflichten können. Gut für GitOps-Setups und kleine Teams.

Das beste Geheimnis ist das, das noch nicht existiert, erst dann erschaffen wird, wenn man es braucht, und dann verfällt, bevor es jemand stehlen kann.

Geheimnisse in Kubernetes einführen

Anwendungen in Kubernetes erwarten gewöhnlich Geheimnisse als Umgebungsvariablen oder Dateien. Wie man sie von einem großen Laden holt:

Externe Geheimnisse (ESO) Synchronisiert Geheimnisse von Vault, OpenBao, Cloud-Geheimnismanagern und anderen in normale Kubernetes-Geheimnisse:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: orders-db
  namespace: shop
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: orders-db-credentials
  data:
  - secretKey: password
    remoteRef:
      key: prod/shop/orders-db
      property: password

Ihr Git-Repository enthält nur eine Referenz, nie das Geheimnis selbst. Apps lesen ein normales Kubernetes-Geheimnis.

Geheimnisse speichern CSI-Fahrer Montiert Geheimnisse direkt aus dem externen Speicher als Dateien, optional ohne ein Kubernetes Secret überhaupt zu erstellen.

- Was ist das ? Injektion fährt einen Seitenwagen, der Geheimnisse für die Kapsel holt und erneuert.

Was auch immer Sie wählen, stellen Sie sicher, Kubernetes Secrets sind verschlüsselt im Ruhezustand in etcd (verwaltete Cluster unterstützen in der Regel KMS-Verschlüsselung) und begrenzen, wer sie mit RBAC lesen kann.

In CI-Pipelines

• Verwendung OIDC um Pipelines zu Ihrer Cloud und zu Vault/OpenBao zu authentifizieren, anstatt langlebige Anmeldeinformationen zu speichern.
• Holen Sie Geheimnisse in der Ausführungszeit, nur in den Jobs, die sie brauchen.
• Maske Die Daten werden in den Protokollen gespeichert und die Druckumgebungsvariablen vermieden.
• Geltungsbereich CI Geheimnisse geschützte Zweige und Umgebungen.

Rotations- und Dynamikgeheimnisse

Ein Geheimnis, das sich nie ändert, ist ein Geheimnis das irgendwann durchsickert. Möglichkeiten, von einfach bis fortgeschritten:

• Planmäßige Rotation von statischen Geheimnissen (Cloud-Geheimnismanager können Datenbankpasswörter automatisch rotieren).
• Dynamische Geheimnisse von Vault/OpenBao: Jede App-Instanz erhält ihre eigenen Anmeldeinformationen, die stundenlang gültig sind.
• Arbeitslast-IdentitätEs ist kein Geheimnis. Pods authentifizieren sich mit ihren Kubernetes-Service-Konto-Identitäten für Cloud-Dienste.

Finden Sie das, was bereits durchgesickert ist.

Bevor Sie das perfekte System bauen, suchen Sie nach dem, was bereits da draußen ist:

• Geflügel oder Trüffelhack Sie können es in Ihren Datensätzen finden, einschließlich der Geschichte.
• GitHub geheimes Scannen mit aktiviertem Schubschutz.
• Drehen Sie alles, was Sie finden. Das Commit zu löschen reicht nicht aus.

Also, wo fange ich an?

Wählen Sie einen zentralen Speicher: Der geheime Manager Ihrer Cloud ist der einfachste Anfang. Installieren Sie den External Secrets Operator. Bewegen Sie die Geheimnisse einer Anwendung dorthin, entfernen Sie sie aus CI-Variablen und Git und drehen Sie sie. Dann wiederhole ich, Service für Service.

Meine Meinung: Geheimnisse sollten abgeholt, nicht kopiert werden. Jede Kopie ist ein zukünftiges Ereignis, das auf ein Datum wartet.

Desly