Wie man Geheimnisse in einer Microservice/Container/Cloud-Umgebung verwaltet?

Question

Microservices und Cloud ist eine Sache. Jeder redet und schreibt darüber. Persönlich denke ich viel über diese Themen nach: Wie kann man davon profitieren? Was sind mögliche Herausforderungen? Wie kann dies die tägliche Entwicklung beschleunigen? Und wie man alle Dinge verwaltet? Eine Frage, die mich seit ein paar Tagen beschäftigt, ist "Wie man Geheimnisse in einer Microservice/Cloud-Umgebung verwaltet?".

Stellen Sie sich eine Firma mit 150 Software-Ingenieuren und verschiedenen Teams mit verschiedenen Produkten vor. Jedes Team erstellt eine Software und jeder Dienst benötigt verschiedene Mengen an Geheimnissen (API-Schlüssel, Passwörter, SSH-Schlüssel, was auch immer). Der Weg der "alten Mode" bestand darin, ein paar Konfigurationsdateien im Format ini/yaml/txt zu erstellen und von dort zu lesen. 12Factor Apps sagen: Mach es pro env vars.

Env vars kann pro Maschine eingestellt werden und die Konfigurationsdateien können auch dort platziert werden. Dies funktioniert, wenn Sie eine Hand voller Maschinen haben und die Bereitstellung von einigen Systemadministratoren durchgeführt wird. Eine der allgemeinen Regeln besagt: "Speichern Sie keine Geheimnisse in einem Git Repo.".

Jetzt kommt die neue Welt. Ever Team ist verantwortlich für die Anwendung, die sie selbst produzieren. Sie sollten vom Team bereitgestellt und ausgeführt werden. So geht unser Unternehmen zu einem Container und Self-Service-Weg (z. B. Mesos und Marathon oder Kubernetes).

Natürlich können Dockerfiles auch Umgebungsvariablen setzen. Und ja, Sie können Ihre Konfigurationsdatei während des Builds in den Docker-Container HINZUFÜGEN. Aber damit kann jeder auf die Geheimnisse (z. B. von anderen Teams) zugreifen. Und niemand weiß, wer diese Geheimnisse benutzt und etwas Gefährliches tut.

Sie möchten auch Ihre Dockerfiles versionieren. Und Anwendungen, die Sie auf Marathon ausführen möchten, sollten ebenfalls versioniert werden (Git oder was auch immer) (und von der REST-API angewendet werden). Wo also alle Geheimnisse für diese Container/Apps speichern und verwalten? Weil mit Scheduler Frameworks wie Swarm und Machine (für Docker), Mesos und Marathon (auch für Docker) oder Kubernetes wissen Sie nicht wo Ihre App läuft. Dies wird über mehrere Maschinen geplant. Und die meisten dieser Tools haben keine Authentifizierung (standardmäßig kann dies natürlich von einem Nginx-Proxy oder etwas hinzugefügt werden).

Eine Idee, um Geheimnisse zu verwalten, ist ein Tool wie Vault. Aber ich habe nie "nativen" Support in einer App gesehen. Gleiches gilt für Blackbox. Und ich weiß nicht, wie das Konfigurationsmanagement das lösen kann. Ich weiß, dass Chef verschlüsselte Databags unterstützt, aber afaik ist es nicht möglich, Chef zum Einrichten/Erstellen von Docker-Containern zu verwenden.

Wie verwalten Sie Geheimnisse in einem Multiteam-Umfeld mit mehreren Ingenieuren in einer Microservice/Container/Cloud-Umgebung?

Answer 1

Es gibt mehrere Lösungen.

Erstens, NICHT setzen Sie Ihre Geheimnisse in das Bild. Das ist nur eine schlechte Idee, wie Sie erkannt haben. Wenn Sie Ihre Secrets zur Build-Zeit nicht hinzufügen, müssen Sie dies zur Laufzeit tun. Dies lässt uns mit ein paar Optionen:

• Verwenden von Umgebungsvariablen wie von der 12 Factor App vorgeschlagen. Sie müssen dann ein Skript schreiben, das die Konfigurationsdateien mit Werten dieser Variablen füllt, wenn der Container gestartet wird.Das funktioniert, aber ich mag es nicht wirklich, da Umgebungsvariablen leicht geleakt werden (sie können in verknüpften Containern und docker inspect gesehen werden und sind oft in Fehlerberichten enthalten). Siehe auch Summon.

• Verwenden Sie Volumes. Mounten Sie die Konfigurationsdatei zur Laufzeit mit den Secrets. Das funktioniert, bedeutet aber, dass Sie eine Datei mit den Geheimnissen auf dem Host haben. Dies wird komplizierter, wenn Sie nicht wissen, auf welchem ​​Host Ihr Container ausgeführt wird, beispielsweise wenn Sie Frameworks wie Swarm und Mesos verwenden.

• Verwenden Sie einen sicheren k/v-Speicher wie Vault/Keywhiz. Wie Sie darauf hingewiesen haben, müssen Sie einige Skripte ausführen, um die Werte in die Anwendung zu bekommen (wie bei env vars). Sie müssen sich auch irgendwie am k/v-Speicher authentifizieren (Sie können sich die Volume-Treiber für Keywhiz und Vault ansehen oder ein Token verwenden, das über eine env var übergeben wird).

Kubernetes hat bereits fairly advanced support for secrets, und ich würde erwarten, dass andere Rahmenbedingungen, um zu sehen, ihre eigenen Lösungen übernehmen.