Dieser Beitrag wurde ursprünglich als Artikel im SDN Magazine am13. Oktober2017 veröffentlicht. Im vergangenen Jahr habe ich mehrere Kunden auf ihrem Weg zu Containerized Delivery auf dem Microsoft-Stack unterstützt. In dieser Blogserie möchte ich acht Praktiken vorstellen, die ich beim Einsatz von Docker für die Containerized Delivery auf dem Microsoft-Stack gelernt habe, sowohl in einer Greenfield- als auch in einer Brownfield-Situation. Im fünften Blogpost dieser Serie möchte ich über Secure Containerized Delivery sprechen.
PRAXIS 5: Sichere Lieferung in Containern
Die Sicherung Ihrer Container-Infrastruktur und -Einsätze ist ein wichtiger Aspekt der Containerized Delivery. Es gibt viele Aspekte, die Sie dabei beachten müssen, daher werde ich die wichtigsten hervorheben.
- Härten Sie Ihre Images, Container, Daemons und HostsWennSie Ihre containerisierte Infrastruktur einrichten, ist es wichtig, dass Sie Ihre Infrastrukturelemente gegen Bedrohungen härten. Um Ihnen dabei zu helfen, hat das Center for Internet Security einen Docker-Benchmark veröffentlicht, der Konfigurations- und Härtungsrichtlinien für Container, Images und Hosts enthält. Werfen Sie einen Blick auf diesen Benchmark unter
cisecurity.org/benchmark/docker/ . Auf der Grundlage dieses Benchmarks steht ein Linux-Container zur Verfügung, der Dutzende gängiger Best Practices für den Einsatz von Docker-Containern in der Produktion auf skriptbasierte Weise überprüft. Leider ist diese Implementierung derzeit nicht für Windows-Hosts verfügbar, aber wenn Sie Linux-Container-Hosts für Ihre ASP.NET Core-Anwendungen verwenden, sollten Sie sich diese Implementierung auf github.com/docker/docker-bench-security unbedingt ansehen. Ein wichtiger Aspekt bei der Absicherung Ihrer Container-Hosts ist der Schutz Ihres Docker-Daemons mit TLS. Eine hervorragende, schnelle und einfache Möglichkeit, dies zu erreichen, ist die Verwendung des Containers dockertls-windows von Stefan Scherer. Dieser Container generiert alle TLS-Zertifikate, die Sie für den Zugriff auf den gesicherten Container-Daemon benötigen. Speichern Sie die .pem-Dateien an einem zentralen, sicheren Ort, damit Sie den Inhalt dieser Dateien verwenden können, sobald Sie auf den gesicherten Docker-Daemon zugreifen wollen. Wenn Sie VSTS für CI/CD verwenden, können Sie den Inhalt der verschiedenen .pem-Dateien direkt im Endpunkt des Docker Host Service speichern.
- Kennen Sie die Herkunft und den Inhalt Ihrer ImagesWiein Praxis 3 erwähnt, gibt es zwei Microsoft-Basis-Images, von denen alle Windows-Container-Images abgeleitet sein sollten. Es gibt jedoch auch viele andere öffentliche Container-Images, die auf DockerHub verfügbar sind, wie microsoft/iis, microsoft/powershell und sogar Images von anderen Anbietern. Die Verwendung dieser Out-of-the-Box-Images beschleunigt die Entwicklung Ihrer Systeme. Die Verwendung von öffentlichen Image-Definitionen kann Ihre Produktionslandschaft jedoch einem hohen Risiko aussetzen. Wie können Sie zum Beispiel sicherstellen, dass diese Images keine Sicherheitslücken enthalten? Wie stellen Sie sicher, dass der Eigentümer des Images die Image-Definition im Laufe der Zeit pflegt, falls Schwachstellen und Exploits entdeckt werden? Es ist wichtig, dass Sie die Herkunft und den Inhalt der Bilder kennen, die Sie konsumieren. Sie können zum Beispiel Docker Notary verwenden, um die Authentizität von Images zu überprüfen, oder Docker Security Scan, um nach Sicherheitslücken in Ihrem Image zu suchen. Sie können auch andere Lösungen wie Aqua und Twistlock verwenden . Welches Tool Sie auch immer verwenden, stellen Sie sicher, dass Sie einen Prozess einrichten, der Sie zwingt, nur gescannte öffentliche Images und vertrauenswürdige Ursprünge zu verwenden. Für bestehende interne Images ist es wichtig, dass Sie regelmäßige Überprüfungen durchführen und diese Images aktiv im Hinblick auf Schwachstellen und Exploits pflegen. Für neue interne Images ist es wichtig, dass Sie die Angriffsfläche so weit wie möglich reduzieren. Viele der sofort einsatzbereiten Images von DockerHub, wie microsoft/iis und microsoft/aspnet, bieten zu viele Funktionen für Ihre Arbeitslast. Bei einem meiner Kunden war dies der Grund dafür, dass wir beschlossen, unser eigenes internes IIS-Basis-Image zu erstellen, in dem nur die Windows-Funktionen und -Dienste aktiviert sind, die wir wirklich benötigen. Das Standard-IIS-Image aktiviert zum Beispiel alle Unterfunktionen des Web-Servers. Das von uns erstellte Image aktiviert nur einige der Unterfunktionen, z.B. Web-Static-Content, Web-Http-Logging, Web-Stat-Compression und Web-Dyn-Compression. Indem wir unser eigenes internes IIS-Image erstellt haben, haben wir unsere Arbeitslast sicherer gemacht und eine bessere Leistung erzielt. Um herauszufinden, welche Windows-Funktionen Sie wirklich benötigen, werfen Sie einen Blick auf die PowerShell-Befehle Get-WindowsOptionalFeature -Online und Get-WindowsFeature.
Mehr aus dieser Serie
- Übung 1 - Kleine wiederverwendbare Bildebenen
- Praxis 2 - Mehrstufige Builds
- Praxis 3 - Halten Sie Windows-Container auf dem neuesten Stand
- Praxis 4 - Gruppenverwaltete Servicekonten
- Praxis 5 - Sichere Lieferung in Containern
- Übung 6 - Der Umgang mit Geheimnissen
- Praxis 7 - Explizites Abhängigkeitsmanagement
- Praxis 8 - Umwelt als Code und Pipeline als individuelle Pipeline
Verfasst von
Cornell Knulst
Cornell works for Xpirit, Hilversum, The Netherlands, as a trainer/architect. He is specialized in the domain of Application Lifecycle Management and Continuous Delivery, with a special focus on Microsoft-based technologies.
Unsere Ideen
Weitere Blogs
Contact



