Die acht Praktiken für Containerized Delivery auf dem Microsoft Stack - PRAXIS 6: Der Umgang mit Geheimnissen

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 sechsten Blogpost dieser Serie möchte ich über den Umgang mit Geheimnissen sprechen .

PRAXIS 6: Der Umgang mit Geheimnissen

Vor der Container-Ära haben wir unsere Geheimnisse (d.h. Anmeldeinformationen, Zertifikate, Verbindungsstrings) an einem bestimmten Ort im Dateisystem abgelegt, neben unseren Anwendungsdateien. In einer containerisierten Welt gibt es ein Problem mit diesem Ansatz. Da Container-Images sowohl die Anwendung als auch die Registry, Umgebungsvariablen und andere Dateisysteminhalte enthalten, würde dieser Ansatz bedeuten, dass jedes Teammitglied die Geheimnisse einsehen kann, indem es einen neuen Container auf der Grundlage dieses Images aufbaut. Der Umgang mit den Geheimnissen von containerisierten Anwendungen bedeutet also, dass Sie Ihre Geheimnisse bei der Container-Initialisierung angeben und sie außerhalb Ihrer Container-Images speichern müssen. Aber wie können Sie das erreichen? Bevor wir uns die Lösung für den Umgang mit Geheimnissen ansehen, müssen Sie genau wissen, was Sie als Geheimnisse deklarieren müssen. Viele Werte in Konfigurationsdateien sind keine Geheimnisse, z.B. Endpunkte, während Kennwörter und SSL-Zertifikate definitiv Geheimnisse sind. Es ist wichtig, sich dieser Trennung zwischen Geheimnissen und Konfigurationseinstellungen bewusst zu sein, denn in einer idealen Welt werden Sie beide auf unterschiedliche Weise verwalten. Was die Konfigurationseinstellungen betrifft, so gibt es mehrere Möglichkeiten, sie zu verwalten. Die Option, die mir am besten gefällt, ist die Verwendung eines Konfigurationscontainers, in dem alle Konfigurationseinstellungen (z.B. Endpunkte) gespeichert werden. Bei der Initialisierung des Containers können Sie auf diesen Container zurückgreifen, um die richtigen Endpunkte für Ihre Anwendung zu erhalten, z.B. einen Topic-Endpunkt des Servicebusses oder einen externen SMS-Endpunkt. Das Schöne an einem Konfigurationscontainer ist, dass Sie den Inhalt aller anderen Container nicht ändern müssen, um die Konfigurationen in verschiedenen Umgebungen wie Dev, Test und Production zu verwalten. Durch die Verwendung von Docker Compose können Sie diesen Konfigurationsspeicher als separaten Dienst definieren und seinen Docker-DNS-Namen verwenden, um die neuesten Konfigurationseinstellungen von diesem Speicher zu erhalten. Bis Anfang dieses Jahres war die am häufigsten verwendete Lösung für den Umgang mit Geheimnissen entweder die Verwendung von Volume Mappings oder die Verwendung von Umgebungsvariablen, die die eigentlichen Geheimnisse enthalten. Keine dieser beiden Optionen war jedoch sehr sicher. Im Falle von Umgebungsvariablen sind Ihre Geheimnisse für jeden Prozess im Container zugänglich, werden in den Zwischenschichten eines Images aufbewahrt, sind in Docker Inspect sichtbar und werden mit jedem Container geteilt, der mit dem Container verbunden ist. Im Falle von Volume Mappings besteht der Nachteil darin, dass Sie Ihre Container vom Inhalt eines Datenvolumens abhängig machen und dies bedeutet, dass dieser Container unnötigerweise zustandsabhängig statt zustandslos wird.

Glücklicherweise besteht seit Anfang dieses Jahres die beste Möglichkeit darin, die Secrets-Verwaltungslösung der verschiedenen Cluster-Implementierungen zu nutzen, z.B. Kubernetes Secrets oder Docker Secrets (Docker 17.05 für Windows-Container). Das Schöne an der Geheimnisverwaltung auf Clusterebene ist, dass die Geheimnisse automatisch auf die Container-Hosts verteilt werden. Ein weiterer Vorteil ist, dass derselbe Geheimname in mehreren Clustern verwendet werden kann. Wenn Sie einen separaten Entwicklungs-, Test- und Abnahmecluster haben, können Sie den Geheimnamen wiederverwenden, und Ihre Container müssen nur den Namen des Geheimnisses kennen, um in allen drei Umgebungen zu funktionieren. Die Erstellung dieser Geheimnisse in Ihrer Container-Cluster-Umgebung kann von den Tools orchestriert werden, die Sie für Ihre Delivery Pipeline verwenden, z.B. VSTS.

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