Sicherheit der Softwarelieferketten in Google Kubernetes Engine unterstützen

In diesem Artikel wird beschrieben, wie Sie dafür sorgen können, dass Ihre Softwarelieferkette einem vorgegebenen und sicheren Ablauf folgt, bevor der Code in einem Cluster der Google Kubernetes Engine (GKE) bereitgestellt wird. Es wird behandelt, wie die Binärautorisierung funktioniert und wie sie am besten mit Google Cloud implementiert und verwendet wird, damit Ihre Bereitstellungspipeline so viele Informationen wie möglich liefern kann, um Genehmigungen in jeder erforderlichen Phase durchzusetzen.

Bausteine für eine sichere Softwarelieferkette

Für die Erstellung und das Deployment containerisierter Anwendungen haben sich unveränderliche Artefakte als Deployment-Einheiten bewährt. So verhält sich Ihre Software immer wie erwartet, auch wenn sie auf vielen Hosts und in vielen Umgebungen bereitgestellt und skaliert wird.

Legen Sie die unveränderlichen Artefakte nach ihrer Erstellung in einem Artefaktspeicher ab, wo sie zur weiteren Verwendung versioniert und katalogisiert werden können.

In verschiedenen Phasen des Releaseprozesses können automatisierte Systeme oder Personen Metadaten hinzufügen, die das Ergebnis einer Aktivität beschreiben. Dieser Vorgang ist mit der Signalisierung eines Prüfpunkts vergleichbar. Beispielsweise können Sie einem Image Metadaten hinzufügen, die angeben, dass es erfolgreich eine Testsuite zur Integration durchlaufen hat.

Wenn die Artefakte dann Metadaten haben, erstellen Sie eine Deployment-Richtlinie, die festlegt, welche Validierungen ein Artefakt bestehen muss, bevor es in der Infrastruktur bereitgestellt werden kann. Integrieren Sie einen Mechanismus in der Infrastruktur, der validiert, ob eine Arbeitslast alle von Ihnen vorgegebenen Prüfpunkte durchlaufen hat, bevor sie zugelassen wird. Diese Art der Validierung wird kurz vor Ausführung des Codes durchgeführt und sorgt dafür, dass ein Deployment keine Phase auslässt, die in Ihrem Ablauf erforderlich ist.

Das folgende Diagramm zeigt einen allgemeinen Verwaltungsprozess für eine Softwarelieferkette.

Verwaltungsprozess der Softwarelieferkette

Sicherheit von Lieferketten in GKE

In der folgenden Tabelle werden die Bausteine der Lieferkette den Google Cloud-Features zugeordnet.

Baustein Google Cloud-Implementierung
Unveränderliches Artefakt Docker-Image
Artefaktspeicher Container Registry
Artefaktmetadaten Hinweis
Artefaktprüfer Attestierer
Artefaktvalidierungen Attestierungen
Deployment-Richtlinie Richtlinie der Binärautorisierung

Das von Ihnen bereitgestellte unveränderliche GKE-Artefakt ist ein Docker-Image. Es wird einmal erstellt und dann an Container Registry, den Artefaktspeicher, übergeben. Dort kann es für eine beliebige Anzahl von GKE-Clustern bereitgestellt werden.

In Container Registry werden den Images mithilfe von Tags Informationen hinzugefügt, die ein einzelnes Metadatenelement darstellen. Am häufigsten werden Docker-Tags in Images verwendet, um die Version der Software oder einen Release-Train wie v2.0.0 oder beta anzugeben. Das sind zwar nützliche Informationen, jedoch können Sie mit Tags keine Details angeben, die das Artefakt beschreiben, z. B. Informationen zum Erstellungsort, zum Quellcode oder zur Genehmigung des Deployments in Produktionsumgebungen. Diese Informationen werden über Attestierungen vermittelt.

Attestierer geben Auskunft darüber, ob Images ein bestimmtes Kriterium erfüllen. Dafür werden in Container Registry den Images Notizen hinzugefügt. Diese Notizen sind über den gesamten Lebenszyklus des Images hinweg abrufbar. Einige Arten von Notizen sind kategorisiert, sodass sich die Informationen zu den Images besser filtern lassen. Die attestation ist eine Art von Notiz, die von Attestierern in Ihrem Projekt hinzugefügt wird. Attestierer validieren beispielsweise, ob Images frei von kritischen Sicherheitslücken sind oder von einem bestimmten Build-System erstellt wurden.

Dem Projekt können Sie einen Attestierer hinzufügen, wenn Sie einen verknüpften öffentlichen Schlüssel von Pretty Good Privacy (PGP) hochladen, um den Attestierer zu erstellen und zu identifizieren. Attestierer können dann Attestierungen erstellen. Dafür signieren sie Nachrichten, in denen angeben ist, welche inhaltsadressierbaren spezifischen Image-Digests attestiert werden.

Im folgenden Diagramm wird einem Image eine Attestierung für einen bestimmten Digest hinzugefügt.

Attestierung zu Image hinzufügen

Mit der Binärautorisierung können Sie eine Richtlinie konfigurieren, die festlegt, welche Attestierungen Ihr Image benötigt, damit es in allen Clustern bereitgestellt werden kann. Die Richtlinie erstellt einen Baustein, um dafür zu sorgen, dass Ihre Images den Pfad durch die Deployment-Pipeline korrekt durchlaufen und keine wichtigen Schritte auslassen. In jeder kritischen Phase der Deployment-Pipeline können Sie eine Attestierung erstellen, die bestätigt, dass das Image den Schritt erfolgreich durchlaufen hat. Attestierungen können entweder von automatisierten Systemen oder von Personen hinzugefügt werden.

Beispiel: Sie möchten bestätigen, dass Ihr Image die Validierungen durch das Qualitätssicherungsteam (QA) erfolgreich durchlaufen hat. Nach Abschluss des Tests signiert eines der Mitglieder des QA-Teams mit einem bestimmten Schlüssel eine Attestierung des Attestierers qa-validated. Diese Attestierung ist erforderlich, damit Ihre Produktionscluster das Image bereitstellen.

In einem ähnlichen Fall möchten Sie vielleicht, dass Ihr Image auf Sicherheitslücken geprüft wurde und keine Unregelmäßigkeiten aufgetreten sind. Dazu kann ein automatisiertes System im Repository nach neuen Images suchen und den Images attestieren, dass sie einen bestimmten Sicherheitsstandard erfüllen. Nachdem das System den Scan auf Sicherheitslücken validiert hat, kann es eine Attestierung aus dem Attestierer not-vulnerable mit seinem kryptografischen Schlüssel signieren und dem Image hinzufügen. Sie können diesen Schlüssel mit Cloud Key Management Service verschlüsseln und sicher in Cloud Storage speichern. Den Zugriff auf den Schlüssel können Sie über IAM steuern und seine Verwendung mit Stackdriver Logging prüfen.

Das folgende Diagramm zeigt Images in Container Registry, denen von Personen und automatisierten Attestierern Attestierungen hinzugefügt wurden.

Automatisch oder von Personen in Container Registry eingefügte Images

Im Rahmen der Binärautorisierung erstellen Sie Richtlinien, die festlegen, mit welchen kryptografischen Schlüsseln Sie Ihre Attestierungen jeweils validieren können. Sie haben auch die Möglichkeit, die Attestierungsvalidierung zu umgehen oder die Binärautorisierung für bestimmte Cluster zu deaktivieren, indem Sie bestimmte Images auf die allowlist setzen.

Google Cloud stellt verwaltete Dienste zum Erstellen und Verwalten Ihrer Softwarelieferkette bereit. Sie können jedoch auch Open-Source-Implementierungen verwenden, um ähnliche Prozesse in anderen Umgebungen zu implementieren.

In der folgenden Tabelle werden Google Cloud-Dienste den Open-Source-Tools mit ähnlichen Funktionen zugeordnet.

Google Cloud Open Source
Container Registry Docker-Verteilung
Metadata API Grafeas
Binärautorisierung Kritis
Scannen auf Sicherheitslücken Clair, Anchore Engine

Best Practices für Pipelines zur kontinuierlichen Bereitstellung

Die Validierung einer Softwarelieferkette ist am effektivsten, wenn Ihre Pipeline zur kontinuierlichen Bereitstellung das automatisierte Deployment des Quellcodes aus einem Code-Repository in der Produktionsinfrastruktur vorsieht. Die jeweiligen Phasen der Pipelines sind von Organisation zu Organisation unterschiedlich. Es gibt jedoch einige allgemein gültige Best Practices, mit denen Sie für ein sicheres Deployment Ihrer Software sorgen können.

Allgemeine Anleitung für die CI/CD-Pipeline

In vielen Organisationen können einzelne Teams jeweils eigene Prozesse und Tools zur kontinuierlichen Bereitstellung auswählen. Diese Flexibilität kann zwar die Autonomie der Teams stärken und ihnen die Nutzung vertrauter Tools ermöglichen, bedeutet aber auch, dass die Durchsetzung der Best Practices für alle Releases sehr kompliziert wird. In einem solchen Fall kann es hilfreich sein, die Releasepipelines der Teams in einem Tool wie Spinnaker zu zentralisieren. Alle Methoden können so an zentraler Stelle in Vorlagen erfasst, freigegeben und geprüft werden.

Image erstellen

Wie für jede andere Lieferkette gilt, dass die Software nur so sicher ist wie die Materialien, die zur Erstellung der ausführbaren Artefakte verwendet werden. Wenn Sie GKE verwenden, müssen Sie dafür sorgen, dass die Images auf sicheren Basisimages basieren.

Ein erster Schritt für maximale Sicherheit der Basisimages ist die Verwendung einer kleinstmöglichen Distribution, die nur die zur Ausführung der Anwendung benötigte Software und Bibliotheken enthält. Für beliebte Distributionen wie Ubuntu, Debian und CentOS bietet die Google Cloud verwaltete Basisimages, die regelmäßig mit Sicherheitspatches aktualisiert werden. Distroless-Images sind Basisimages, die nur Bibliotheken und Tools enthalten, die zur Ausführung von in verschiedenen Programmiersprachen geschriebenen Anwendungen erforderlich sind. Versuchen Sie, nach Auswahl der Basis so wenig wie möglich hinzuzufügen. Mit den mehrstufigen Builds von Docker können Sie die Abhängigkeiten zur Erstellungszeit von den Laufzeitabhängigkeiten trennen und dadurch die Angriffsfläche verkleinern.

Nach der Erstellung des Images prüfen Sie, ob das Image die Richtlinien Ihrer Organisation erfüllt. Zu diesem Zweck können Sie Containerstrukturtests erstellen, die Inhalte und Metadaten eines Images validieren. Sie können auch container-diff verwenden, um vorhandene und neu erstellte Container zu vergleichen.

Wenn Sie die Inhalte Ihres Anwendungsimages eingegrenzt haben, versuchen Sie, den Umfang der in Ihren Clustern zulässigen Images von Drittanbietern zu prüfen und zu reduzieren. Mit der Binärautorisierung können Sie Images auf die allowlist setzen, für die die Attestierungsanforderungen nicht gelten sollen. Der allowlist-Eintrag sollte für die Images, die Sie benötigen, aber nicht über Ihre Pipeline zur Artefakterstellung erstellen können, so spezifisch wie möglich sein.

Weitere Informationen zur Erstellung von Containern finden Sie in der Dokumentation zu den Best Practices für die Containererstellung.

Prüfung von Images auf Sicherheitslücken aktivieren

Sie sollten in Ihren Projekten das Scannen auf Sicherheitslücken in Container Registry aktivieren. Der Scan liefert Informationen zu potenziellen Sicherheitsproblemen in Ihren Docker-Images. Die automatisierten Scans, die bei der Übertragung Ihrer Images sofort gestartet werden, können Ihnen Aufschluss über den Schweregrad der Sicherheitslücken in den Images geben. Zusätzlich zur Prüfung auf Sicherheitslücken vor dem Deployment sollten Sie Ihre Images nach dem Deployment noch einmal prüfen. Dabei können neue Lücken entdeckt werden. Der Scan auf Sicherheitslücken prüft fortlaufend alle Images, die in den letzten 30 Tagen aus der Registry abgerufen wurden. Sie können Pub/Sub verwenden, um Benachrichtigungen zu erhalten, wenn in Ihren Images Sicherheitslücken gefunden werden.

Richtlinie während des Deployments validieren

Die Imagevalidierung während des Deployments bietet einen zusätzlichen Schutz der Softwarelieferkette. Das Deployment ist der letzte Schritt in einer Pipeline zur kontinuierlichen Bereitstellung. Sinnvollerweise sollte hier geprüft werden, ob in Ihrem Prozess alle Phasen und alle Prüfpunkte durchlaufen wurden. So können Sie ausschließen, dass Nutzer, die sich Zugriff auf die Anmeldedaten Ihrer Cluster verschafft haben, schädliche Images bereitstellen.

Mit der Binärautorisierung können Sie für alle Cluster im Projekt eine Standardregel konfigurieren und diese bei Bedarf mit clusterspezifischen Konfigurationen überschreiben. Beispiel: Sie möchten, dass alle Cluster durch Attestierungen aus dem Scan auf Sicherheitslücken und der QA-Validierung geschützt sind. Gleichzeitig möchten Sie jedoch Entwicklern ermöglichen, im development-Cluster ohne Störung durch QA-Validierungen mit neuen Technologien und Images zu experimentieren. Weitere Informationen zu den Richtlinien der Binärautorisierung finden Sie in der Dokumentation Referenz zu YAML-Richtlinien.

Beispielpipeline

Die folgende Beispielpipeline ist in zwei Hauptphasen unterteilt: die Erstellungs- und die Deployment-Phase.

Phasen zur Erstellung und zum Deployment in einer Beispielpipeline

In der folgenden Tabelle sind die Schritte der Pipeline im Detail beschrieben. An den jeweiligen Stellen sind die hinzuzufügenden Attestierungen angegeben.

Schritt Zusammenfassung Beschreibung Bestätigungs-
symbol
1 Quellcode abrufen Der im Build-System zu verwendenden Quellcode der gewünschten Version wird abgerufen.
2 Einheitentests ausführen Vor Erstellung eines Artefakts wird geprüft, ob der Code alle Einheitentests erfolgreich durchlaufen hat.

Einheitentests ausführen

3 Docker-Image erstellen Mit dem Dockerfile im lokalen Quellcode wird ein Image erstellt, das in Container Registry übertragen werden kann.
4 Konformität des Docker-Image mit Richtlinie prüfen Mit Containerstrukturtests wird bestätigt, dass der Inhalt des Images korrekt ist und die Befehle im Image die korrekte Ausgabe zurückgeben.

Konformität des Docker-Image mit Richtlinie prüfen

5 Image in Container Registry übertragen Nach dem Einheitentest des Codes und der Validierung des Imageinhalts wird das Image in Container Registry übertragen. Ein Scannen auf Sicherheitslücken wird automatisch gestartet.
6 Achten Sie darauf, dass das Image keine kritischen Sicherheitslücken aufweist Nach Abschluss des mehrminütigen Scans auf Sicherheitslücken werden den Imagemetadaten Notizen zu allen aufgetretenen Common Vulnerabilities and Exposures (CVEs) hinzugefügt. Wurden keine kritischen Sicherheitslücken gefunden, wird eine Attestierung hinzugefügt.

Achten Sie darauf, dass das Image keine kritischen Sicherheitslücken aufweist

7 Image für Staging bereitstellen Das Deployment in einer Vorproduktionsumgebung wird initiiert. Hier können Änderungen validiert und in möglichst produktionsnahen Szenarien beobachtet werden.

Image für Staging bereitstellen

8 Code für Deployment in Produktion genehmigen Sprechen alle Signale dafür, dass die Änderungen den Anforderungen entsprechen, wird das Deployment in der Produktion genehmigt.
9 Code auf Produktionsclustern bereitstellen Das Image kann nun auf allen Clustern aktualisiert werden. Vor Ausführung der Anwendung prüft jeder Cluster, ob alle Attestierungen vorhanden sind.

Beispiele für Attestierungen

Beispiele für Attestierungen, die Sie Ihrer Releasepipeline hinzufügen können:

  • Die Analyse auf Sicherheitslücken ergab keine kritischen Sicherheitslücken.
  • Die manuelle QA-Validierung war erfolgreich.
  • Die gesamte im Image enthaltene Software wurde ordnungsgemäß lizenziert.
  • Das Artefakt wurde in einem vertrauenswürdigen Build-System erstellt.

Weitere Informationen