Ich habe einen Pod, der Container ausführt, die Zugriff auf vertrauliche Informationen wie API-Schlüssel und DB-Kennwörter benötigen. Im Moment sind diese sensiblen Werte wie folgt in die Controllerdefinitionen eingebettet:
%Vor%, die dann im Docker-Container als Umgebungsvariable $DB_PASSWORD verfügbar sind. Alles ziemlich einfach.
Aber ihre Dokumentation zu lesen auf Secrets , sie ausdrücklich sagt, dass setzt sensible Konfigurationswerte in der Definition Verletzungen am besten Praxis und ist möglicherweise ein Sicherheitsproblem. Die einzige andere Strategie, die ich mir vorstellen kann, ist die folgende:
Dies erscheint ziemlich kompliziert, aber sicherer und flexibler, da die Werte nicht mehr statisch sind und im Klartext gespeichert werden.
Also ist meine Frage, und ich weiß, dass es keine vollkommen objektive ist, ob das absolut notwendig ist oder nicht? Nur Admins können die RC-Definitionen an erster Stelle sehen und ausführen; Wenn jemand den kubernetes-Meister verletzt hat, müssen Sie sich um andere Sorgen sorgen. Der einzige Vorteil, den ich sehe, ist, dass es keine Gefahr gibt, dass Geheimnisse im Klartext an das Dateisystem übergeben werden ...
Gibt es andere Möglichkeiten, Docker-Container auf sichere Weise mit geheimen Informationen zu füllen?
Wenn Sie nicht viele Megabyte config haben, klingt dieses System unnötig komplex. Die vorgesehene Nutzung ist nur für Sie jede Konfiguration in ein Geheimnis gestellt, und die Schoten die Config benötigen kann dieses Geheimnis als Volume.
Sie können dann eine Vielzahl von Mechanismen verwenden, um diese Konfiguration an Ihre Aufgabe zu übergeben, z. Wenn es die Umgebungsvariablen source secret/config.sh; ./mybinary ist, ist das ein einfacher Weg.
Ich glaube nicht, dass Sie zusätzliche Sicherheit erhalten, wenn Sie einen privaten Schlüssel als Geheimnis speichern.
Ich würde persönlich entscheiden, einen Remote-Keymanager zu verwenden, auf den Ihre Software über eine HTTPS-Verbindung über das Internet zugreifen kann. Zum Beispiel würde Keywhiz oder Vault wahrscheinlich passen die Rechnung.
Ich würde den Schlüsselverwalter in einem separaten isolierten Teilnetz hosten und die Firewall so konfigurieren, dass nur der Zugriff auf IP-Adressen möglich ist, von denen ich erwartete, dass sie die Schlüssel benötigen. Sowohl KeyWhiz als auch Vault verfügen über einen ACL-Mechanismus, sodass Sie möglicherweise gar nichts mit Firewalls zu tun haben, aber es ist nicht schaden, darüber nachzudenken - der Schlüssel hier ist jedoch, den Keymanager in einem separaten Netzwerk zu hosten und sogar möglich ein separater Hosting-Provider.
Ihre lokale Konfigurationsdatei im Container enthält nur die URL des Schlüsseldienstes und möglicherweise Anmeldeinformationen zum Abrufen des Schlüssels vom Schlüsselverwalter. Die Anmeldeinformationen würden für einen Angreifer nutzlos sein, wenn er nicht mit der ACL übereinstimmt. IP-Adressen.
Tags und Links security docker kubernetes confd