Erfahren Sie, wie Sie die Sicherheit Ihrer Container-Bilder durch digitale Signaturen in Kubernetes erhöhen können.
Die Kubernetes-Community hat mit der Version v1.24 den Schritt gewagt, ihre Container-Image-basierten Artefakte digital zu signieren. Mit der Umstellung des entsprechenden Enhancements von alpha auf beta in v1.26 wurden auch die Signaturen für binäre Artefakte eingeführt. Dies hat andere Projekte inspiriert, ebenfalls Bildsignaturen für ihre Releases zu implementieren. Aber wie verifiziert man diese Signaturen effektiv?
Für Entwickler und DevOps-Teams bedeutet dies, dass sie nun die Möglichkeit haben, Container-Images automatisiert zu signieren und diese Signaturen zu überprüfen. Dies kann entweder innerhalb der eigenen CI/CD-Pipelines geschehen, beispielsweise durch GitHub Actions, oder durch den Kubernetes-Image-Promotion-Prozess, der die Signierung automatisch vornimmt. Voraussetzung dafür ist, dass das Projekt Teil der kubernetes oder kubernetes-sigs GitHub-Organisation ist.
Angenommen, Ihr Projekt produziert jetzt signierte Container-Image-Artefakte. Wie können Sie die Signaturen nun überprüfen? Manuell ist dies möglich, aber nicht praktikabel für Produktionsumgebungen. Hier kommen Tools wie der sigstore policy-controller ins Spiel. Diese Tools nutzen eine höhere API-Ebene durch Custom Resource Definitions (CRD) und integrierte Admission Controller und Webhooks, um die Signaturen zu verifizieren.
Der allgemeine Ablauf für eine Überprüfung durch einen Admission Controller sieht folgendermaßen aus:
Ein wesentlicher Vorteil dieser Architektur ist die Einfachheit: Eine einzige Instanz im Cluster validiert die Signaturen, bevor ein Image-Pull im Container-Runtime auf den Knoten stattfinden kann. Dies wird vom Kubelet eingeleitet. Allerdings bringt dies auch die Herausforderung der Trennung mit sich: Der Knoten, der das Container-Image ziehen soll, ist nicht notwendigerweise derselbe, der die Admission durchführt. Dies bedeutet, dass bei einem Kompromittieren des Controllers eine clusterweite Durchsetzung der Richtlinien nicht mehr möglich ist.
Eine Lösung für dieses Problem besteht darin, die Richtlinienbewertung direkt im Container Runtime Interface (CRI)-kompatiblen Container-Runtime durchzuführen. Die Runtime ist direkt mit dem Kubelet auf einem Knoten verbunden und führt alle Aufgaben wie das Ziehen von Images aus. CRI-O ist eine solche Runtime und wird in v1.28 vollständige Unterstützung für die Überprüfung von Container-Image-Signaturen bieten.
Wie funktioniert das? CRI-O liest eine Datei namens policy.json, die alle definierten Regeln für Container-Images enthält. Zum Beispiel können Sie eine Richtlinie definieren, die nur signierte Images quay.io/crio/signed für beliebige Tags oder Digests erlaubt:
{ “default”: { “type”: “signed”, “locations”: [ { “location”: “quay.io/crio/signed”, “signature”: true } ] } }
Mit diesen neuen Möglichkeiten zur Überprüfung von Container-Image-Signaturen können Entwickler und DevOps-Teams sicherstellen, dass ihre Anwendungen sicher und zuverlässig sind. ayedo freut sich, als Partner in der Kubernetes-Welt an Ihrer Seite zu stehen und Sie auf Ihrem Weg zu unterstützen.
Quelle: Kubernetes Blog
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Kubernetes ist der De-facto-Standard für die Container-Orchestrierung, aber wenn es um den Umgang mit spezialisierter Hardware wie GPUs und anderen Beschleunigern geht, wird es kompliziert. In diesem …
In Branchen, in denen Systeme äußerst zuverlässig laufen müssen und strenge Leistungsanforderungen bestehen, wie beispielsweise in der Telekommunikation, Hochleistungs- oder KI-Computing, benötigen …
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →
