‫Ich verwende Docker-Geheimnisse für meine Passwörter, aber dadurch
‫wird nur eine RAM-Datei im Container erstellt.
‫Wenn sich jemand in den Container gehackt hat, kann er
‫die Datei genauso sehen wie meine Anwendung.
‫Ja und nein.
‫Toll. Wir werden weiter reden. Gibt es einen
‫besseren Weg, dies zu tun? Den Inhalt des Geheimnisses verschlüsseln?
‫Dann entschlüsseln Sie die Anwendung auf eine Weise, die ein
‫Hacker nicht herausfinden konnte.
‫Die Realität
‫hier ist, dass Ihre Anwendung irgendwo ihr Geheimnis haben muss,
‫und sie werden unverschlüsselt im Speicher gespeichert, richtig.
‫Alles, was ich weiß, was verschlüsselt, entschlüsselt
‫es in den Speicher. Wenn ein Hacker
‫Wurzel in Ihrem Container hat, kann
‫er dieses Zeug bekommen.
‫Wenn sie klug genug sind, werden sie in der Lage
‫sein, das Zeug richtig hinzubekommen.
‫Im ersten Schritt wird Ihre Anwendung nicht als
‫Root im Container ausgeführt.
‫Dann können sie sich mit nichts außerhalb
‫der Anwendung herumärgern. Sie können keine anderen Systemdienstprogramme
‫im Container ausführen, die möglicherweise den gesamten Speicher lesen können.
‫Die zweite Sache ist, dass die
‫sicherste Möglichkeit, die wir gesehen haben, so etwas wie Tresor
‫und Einmalpasswörter ist, bei denen sie erstellt werden, von
‫Ihrer App verwendet werden und dann weggeworfen werden
‫und nicht mehr gut. Die Realität ist, dass die meisten
‫Menschen dafür nicht bereit sind. Die meisten Apps können damit nicht umgehen.
‫Sie können einen Twitter-API-Schlüssel nicht alle fünf Minuten
‫für jede gestartete App drehen.
‫Sachen wie diese. Das zweitbeste ist,
‫zu verhindern, dass diese Datei dauerhaft auf der Festplatte
‫gespeichert wird.
‫Eine Kubernetes-Sicherheit
‫und Docker-Sicherheit, die ... Traurige Geheimnisse, Kubernetes-Geheimnisse und
‫Swarm-Geheimnisse sind einige der besten Möglichkeiten, die
‫ich je gesehen habe, um Passwörter
‫in einer gefälschten Datei im
‫RAM zu speichern. Sie können diese Berechtigungen so festlegen, dass
‫sie nur von Ihrer App gelesen werden können.
‫Wenn also jemand mit einem anderen Benutzer in Kontakt kommt, muss
‫sich nicht unbedingt ein anderer Benutzer
‫im Container befinden, sondern Sie können diese Benutzer so sperren, dass sie nur
‫lesbar sind und nur vom Benutzer gelesen werden können Das
‫ist deine App. Das ist die Art von Sachen, richtig.
‫Also, das ist es wirklich.
‫Das einzige, was ich besser gesehen habe, speichert sie noch im
‫Speicher, speichert sie noch unverschlüsselt.
‫Es speichert sie einfach nicht lokal.
‫Sie müssen also eine Remote-API wie
‫Vault, HashiCorp's Vault oder ein anderes System verwenden,
‫das Einmalpasswörter liefert. Aber auch diese Dinge müssten über Ihr
‫gesamtes System hinweg erstellt werden. Sie müssten das
‫Ganze entwerfen. Und das ist eine Menge Arbeit, richtig.
‫Mit den Geheimnissen in Kubernetes und Swarm
‫können Sie diese Aufgaben normalerweise noch am
‫selben Tag erledigen. Sie können dies für
‫nahezu jede App implementieren, auch wenn sie als Umgebungsvariablen festgelegt werden
‫muss, da ältere Anwendungen Dinge in Umgebungsvariablen erfordern.
‫Sie können sie also in Geheimnissen haben und diese
‫Geheimnisse dann zur Laufzeit in Umgebungsvariablen speichern,
‫wenn dies erforderlich ist. Aber ich würde sagen,
‫dass meine Beratungskunden in 99% der Fälle mit Legacy-Anwendungen zu tun haben.
‫Wenn ich Vermächtnis sage, meine ich wirklich alles vor
‫Containern, was die meisten Anwendungen sind, richtig.
‫Wir haben 30 Jahre damit verbracht, Anwendungen ohne Container
‫zu erstellen, bevor wir sie hatten.
‫Wir haben also viele normale Sachen.
‫Die meisten Teams versuchen also nur, Dinge in Container zu
‫packen und verschlüsselt auf der Festplatte zu speichern.
‫Wenn sie sich auf der Festplatte befinden, werden sie verschlüsselt.
‫Kubernetes und Swarm können das beide.
‫Ich denke, wenn Sie Geheimnisse verwenden, sind Sie bereits
‫besser als 99% der Leute, die ich sehe, weil nur
‫sehr wenige Leute Orchestrierung und auch Geheimnisse verwenden.
‫Es ist eine sehr, sehr kleine Gruppe von Leuten.
‫Also, ja, ich denke du bist ziemlich gut dort.