Snyk Container und Cloud Native Buildpacks: Cloud Native Application Security richtig umgesetzt

Sie setzen also Microservices in Containern ein? Herzlichen Glückwunsch! Das ist ein wichtiger Schritt, um den geschäftlichen Anforderungen gerecht zu werden und Anwendungen so schnell wie möglich an Ihre Kunden auszuliefern. Doch wie lassen sich potenzielle Risiken einer schnelleren Softwarebereitstellung mindern? Ganz einfach: mit Snyk.

Snyk Container hilft Ihnen in Kombination mit einem Build-Tool, das OCI-konforme Container-Images erstellt, dieses Risiko zu mindern und sich auf das wirklich Wichtige zu konzentrieren: ein erstklassiges Kundenerlebnis. Sehen wir uns an, wie das funktioniert.

Der Unterschied zwischen Docker-Images und OCI-konformen Images

Damit Images, die mit beliebigen Build-Tools erstellt wurden, von allen Container-Runtimes ausgeführt werden können, hat die Open-Source-Container-Community die Open Container Initiative (OCI) ins Leben gerufen. Sie definiert Industriestandards für Container-Image-Formate und Runtimes. Mit einem OCI-Image kann jede Container-Runtime, die dieOCI Runtime Specification implementiert, das Image extrahieren und in einer isolierten Umgebung ausführen.

Wahrscheinlich haben Sie schon vom Unternehmen Docker gehört und fragen sich vielleicht, worin der Unterschied zwischen OCI-Images und Docker-Images besteht. Die Antwort lautet heute: „nicht viel“. Es gibt hier und da einige ältere Docker-Images, die vor den OCI-Spezifikationen erstellt wurden. Formal werden diese als Docker-v1-Spezifikationsformate bezeichnet. Sie sind nicht mit dem Docker-v2-Schema kompatibel, das der OCI gespendet wurde und die Grundlage der OCI-Spezifikationen bildet. Diese v1-Images stammen jedoch aus dem Jahr 2017. Heute basieren nahezu alle Container-Registries, Kubernetes-Plattformen und Container-Runtimes auf den OCI-Spezifikationen. Dazu gehören die Docker Engine, Docker Hub sowie weitere Docker-Tools und -Produkte.

Warum ist das alles wichtig? Die offenen Spezifikationen haben anderen Gruppen innovative Wege zum Erstellen von Containern ermöglicht. Da sie alle OCI-konforme Images erstellen, können Sie diese überall ausführen – und Sicherheitstools wie Snyk Container helfen Ihnen dabei, sie sicher zu halten. Letztendlich sollen sich Entwicklungsteams wahrscheinlich auf den Kern des Anwendungscodes konzentrieren, statt sich Gedanken darüber zu machen, wie die Dockerfile aussehen muss, stundenlang zu prüfen, welche Open-Source-Bibliotheken verwendet werden sollten, oder die Tausenden von Image-Tags auf Docker Hub zu durchforsten, um das passende Basis-Image zu finden. Sehen wir uns eine Methode an, mit der sich Container direkt aus dem Quellcode erstellen lassen: Cloud Native Buildpacks.

Cloud Native Buildpacks: In einem Schritt vom Quellcode zum Container

Cloud Native Buildpacks (CNBs) wandeln Ihren Anwendungscode in vollständig konforme OCI-Images um, die in jeder Cloud ausgeführt werden können. Außerdem unterstützen sie alle gängigen Programmiersprachen. Das Container-Problem ist gelöst – mit Kontrolle, Compliance und einfacher Wartbarkeit!

Wenn Sie Heroku, die Pivotal-PaaS-Plattform (heute VMware Tanzu Application Service) oder die zugehörige Open-Source-Plattform Cloud Foundry verwendet haben, kennen Sie vielleicht etwas Ähnliches wie Buildpacks. Sie übertragen einfach Ihren Code an diese Dienste, und diese verpacken ihn in ein geeignetes Runtime-Objekt. CNBs bieten dieselbe Erfahrung für OCI-Images. Entwickler schreiben ihren Code, und CNBs erstellen alle Anwendungsabhängigkeiten und verpacken alles, was die Anwendung benötigt, in ein Container-Image.

So funktionieren Cloud Native Buildpacks (von vmware Tanzu Developer Center)

Beispiel

1$ pack build pasapples/pbs-demo-image:latest --builder paketobuildpacks/builder:base --publish --path ./target/springbootemployee-0.0.1-SNAPSHOT.jar

Was genau erstellen Cloud Native Buildpacks?

Wie jedes Tool zum Erstellen von Images erstellen Cloud Native Buildpacks eine Reihe von Dateisystemebenen. Sie enthalten die Runtime, Ihre Anwendung und alle ihre Abhängigkeiten sowie die Metadaten, anhand derer die Container-Engine weiß, wie sie die Anwendung starten soll. Hier sehen Sie die Informationen zu den Ebenen für das obige Beispiel. Sie wurden mit dem Befehl docker image history abgerufen:

1$ docker image history pasapples/pbs-demo-image:latest
2IMAGE      CREATED    CREATED BY   SIZE  COMMENT
35d29940d2e52   41 years ago            68kB
4<missing>  41 years ago            46.3MB
5<missing>  41 years ago            10B
6<missing>  41 years ago            7.05MB
7<missing>  41 years ago            451kB
8<missing>  41 years ago            2.09MB
9<missing>  41 years ago            7.23MB
10<missing>  41 years ago            3.04MB
11<missing>  41 years ago            140MB
12<missing>  41 years ago            214B
13<missing>  41 years ago            6.69MB
14<missing>  41 years ago            2.27MB
15<missing>  41 years ago            398kB
16<missing>  41 years ago            6.51MB
17<missing>  41 years ago            7B
18<missing>  41 years ago            745B
19<missing>  41 years ago            987kB
20<missing>  41 years ago            63.2MB

Der Zeitstempel „vor 41 Jahren“ dient der Unterstützung reproduzierbarer Builds. Weitere Informationen dazu finden Sie hier: Time Travel with Pack

Mit dem Tool dive können wir den Inhalt der Ebenen genauer untersuchen. Im Fenster oben links im folgenden Screenshot haben wir die vorletzte Ebene des Images ausgewählt (in dive werden die Ebenen von unten nach oben aufgelistet, während sie in der Ausgabe des oben gezeigten Builds in umgekehrter Reihenfolge erscheinen). Rechts sehen wir den Inhalt dieser Ebene: JAR-Dateien einer Spring-Boot-Anwendung in unserem OCI-Image. CNB hat all diese Bestandteile anhand unseres Quellcodes für uns zusammengestellt.

OCI-Container-Image-Sicherheit mit Snyk Container

Snyk Container findet Schwachstellen in Containern und Kubernetes-Workloads während des gesamten SDLC, indem alle konformen OCI-Images gescannt werden – auch solche, die mit Cloud Native Buildpacks oder anderen Tools zum Erstellen von OCI-Images erstellt wurden. Doch Snyk listet nicht nur alle Schwachstellen in Ihrem Container auf: Snyk Container gibt Ihnen Empfehlungen, mit denen Sie schnell bessere und weniger anfällige Container erstellen können. Dank unserer neuen und verbesserten Funktionen zur Erkennung von Basis-Images können wir dieselben Empfehlungen geben, die bisher nur verfügbar waren, wenn Nutzer eine Dockerfile angegeben hatten!

Automatisierte Behebung von Schwachstellen in Basis-Images mit Snyk Container

Erweitern Sie Ihre Sicherheitsfunktionen, indem Sie Entwickler dabei unterstützen, zahlreiche Schwachstellen schnell zu beseitigen – durch ein Upgrade auf ein sichereres Basis-Image oder einen erneuten Build, wenn das Basis-Image veraltet ist.

Beim Scannen dieser OCI-Images kann Snyk erkennen, auf welchem Basis-Image Ihre Images aufbauen, und Basis-Images mit wenigen Schwachstellen vorschlagen, wie unten dargestellt.

Welches Basis-Image könnten wir für unseren OCI-Container verwenden oder kürzlich aktualisieren?

Diese Empfehlungen für Basis-Images sind unabhängig davon verfügbar, wie und wo Sie Ihre Images im Lebenszyklus scannen. Im obigen Beispiel ist ein auf Docker Hub gespeichertes Image zu sehen. Unten haben wir ein Image mit der Snyk CLI gescannt. Das gilt auch für Scans in Ihren CI-Pipelines. Snyk kann Basis-Images mit wenigen Schwachstellen vorschlagen, wie unten dargestellt:

1$ snyk container test pasapples/pbs-demo-image
2
3Testing pasapples/pbs-demo-image...
4
5✗ High severity vulnerability found in openssl
6  Description: NULL Pointer Dereference
7  Info: https://snyk.io/vuln/SNYK-UBUNTU1804-OPENSSL-1089073
8  Introduced through: openssl@1.1.1-1ubuntu2.1~18.04.5, ca-certificates@20180409, openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
9  From: openssl@1.1.1-1ubuntu2.1~18.04.5
10  From: ca-certificates@20180409 > openssl@1.1.1-1ubuntu2.1~18.04.5
11  From: openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
12  and 1 more...
13  Fixed in: 1.1.1-1ubuntu2.1~18.04.9
14
15...
16
17Organization:  pas.apicella-41p
18Package manager:   deb
19Project name:  docker-image|pasapples/pbs-demo-image
20Docker image:  pasapples/pbs-demo-image
21Platform:      linux/amd64
22Base image:    ubuntu:bionic-20200403
23Licenses:      enabled
24
25Tested 93 dependencies for known issues, found 57 issues.
26
27Base Image          Vulnerabilities  Severity
28ubuntu:bionic-20200403  49           0 critical, 0 high, 16 medium, 33 low
29
30Recommendations for base image upgrade:
31
32Minor upgrades
33Base Image Vulnerabilities  Severity
34ubuntu:bionic  25           0 critical, 0 high, 3 medium, 22 low
35
36Major upgrades
37Base Image  Vulnerabilities  Severity
38ubuntu:rolling  17           0 critical, 0 high, 2 medium, 15 low

Schwachstellen in Anwendungen und Containern gemeinsam erkennen

Möglicherweise haben Sie nicht immer Zugriff auf den ursprünglichen Quellcode, der in Ihren Containern ausgeführt wird. Schwachstellen in den Code-Abhängigkeiten sind dennoch wichtig. Snyk kann im Rahmen des Container-Scans Open-Source-Abhängigkeiten für gängige Programmiersprachen erkennen und überwachen.

Die Basisschicht im Vergleich zu den Open-Source-Abhängigkeiten, übersichtlich dargestellt für ein CNB-OCI-Image.

Entwicklern helfen, sich auf Schwachstellen mit dem höchsten Risiko zu konzentrieren

Snyk hilft Ihnen, sich auf die Probleme mit der höchsten Priorität zu konzentrieren, statt Hunderte von Problemen einzeln zu priorisieren. Ignorieren oder schließen Sie Schwachstellen in Basis-Images aus und nutzen Sie Risikosignale wie den Reifegrad von Exploits und unsichere Workload-Konfigurationen. So können Teams das übliche Rauschen in Berichten zu Container-Schwachstellen ausblenden.

Snyk Container ist nur ein Bestandteil der Plattform Snyk Cloud Native Application Security. Sie wurde entwickelt, um Entwickler beim Erkennen und Beheben von Schwachstellen in Cloud-Native-Anwendungen zu unterstützen. Probieren Sie sie noch heute aus.