Konzepte: Kontinuierliches Patchen in der Azure-Containerregistrierung

Das Feature für kontinuierliches Patchen von Azure Container Registry automatisiert die Erkennung und Behebung von Sicherheitsrisiken auf Betriebssystemebene in Containerimages. Wenn Sie regelmäßige Scans mit Trivy planen und Sicherheitsfixes mithilfe von Copa anwenden, können Sie sichere, up-to-Datumsbilder in Ihrer Registrierung verwalten, ohne dass Zugriff auf Quellcode oder Buildpipelines erforderlich ist. Passen Sie den Zeitplan und die Zielimages frei an, um Ihre Azure Container Registry(ACR)-Umgebung sicher und konform zu halten.

Anwendungsfälle

Im Folgenden finden Sie einige Szenarien für die Verwendung des kontinuierlichen Patchings:

• Sicherstellen der Containersicherheit und -hygiene: Durch kontinuierliches Patchen können Benutzer Schwachstellen und Gefahren (CVEs - Common Vulnerabilities and Exposures) in Betriebssystemcontainern schnell beheben, ohne dass diese vollständig vom Upstream neu erstellt werden müssen.
• Geschwindigkeit der Verwendung: Durch kontinuierliches Patchen wird die Abhängigkeit von Upstreamupdates für bestimmte Bilder entfernt, indem Pakete automatisch aktualisiert werden. Sicherheitsrisiken können täglich auftreten, während beliebte Bildverleger möglicherweise nur einmal im Monat eine neue Version anbieten. Durch kontinuierliches Patchen können Sie sicherstellen, dass Containerimages in Ihrer Registrierung gepatcht werden, sobald die neuesten Betriebssystemrisiken erkannt werden.

Preisgestaltung

Kontinuierliches Patchen wird unter einem Verbrauchsmodell betrieben. Jeder Patch verwendet Computeressourcen, die pro Standardpreis für den ACR-Vorgang von 0,0001 USD/Sekunde der ausgeführten Aufgabe berechnet werden. Weitere Informationen finden Sie auf der ACR-Preisseite.

Einschränkungen bei der Vorschau

Kontinuierliches Patchen befindet sich derzeit in der öffentlichen Vorschau. Es gelten die folgenden Einschränkungen:

• Windows-basierte Containerimages werden nicht unterstützt.
• Es werden nur Sicherheitsrisiken auf Betriebssystemebene gepatcht, die von Systempaketen stammen. Dazu gehören Systempakete im Containerimage, das von einem Betriebssystempaket-Manager wie "apt" und "yum" verwaltet wird. Sicherheitsrisiken, die aus Anwendungspaketen stammen, z. B. von Programmiersprachen wie Go, Python und NodeJS verwendete Pakete, können nicht gepatcht werden.
• End of Service Life (EOSL)-Images werden von fortlaufenden Patches nicht unterstützt. EOSL-Bilder beziehen sich auf Bilder, bei denen das zugrunde liegende Betriebssystem keine Updates, Sicherheitspatches und technischen Support mehr anbietet. Beispiele hierfür sind Bilder, die auf älteren Betriebssystemversionen wie Debian 8 und Fedora 28 basieren. EOSL-Bilder werden trotz Sicherheitsrisiken vom Patch übersprungen . Der empfohlene Ansatz besteht darin, das zugrunde liegende Betriebssystem Ihres Images auf eine unterstützte Version zu aktualisieren.
• Images mit mehreren Bogen werden nicht unterstützt.
• Für kontinuierliches Patchen wird eine 100-Bildbegrenzung erzwungen.
• Kontinuierliches Patchen ist nicht kompatibel mit aktivierten ABAC-Registrierungen (Attributbasierte Zugriffssteuerung) und Repositories, die über Pull Through Cache (PTC) Regeln verfügen.
• Azure-Abonnements für die "kostenlose Testversion" mit kostenlosen Gutschriften werden nicht unterstützt, da kostenlose Testkonten keinen ACR-Aufgabenzugriff haben.

Wichtige Konzepte

Da durch kontinuierliches Patchen in ACR ein neues Image pro Patch erstellt wird, basiert ACR auf einer Tag-Konvention, um gepatchte Bilder zu versionieren und zu identifizieren. Die beiden Hauptansätze sind inkrementell und floatierend.

Inkrementelles Tagging

Funktionsweise:

Mit jedem neuen Patch ein numerisches Suffix (z. B. -1, -2 usw.) am ursprünglichen Tag erhöht. Wenn das Basisimage beispielsweise python:3.11 lautet, erstellt der erste Patch python:3.11-1, und ein zweiter Patch auf diesem Basistag erstellt python:3.11-2.

Spezielle Suffixregeln:

• -1 an -999: Diese werden als Patchtags betrachtet.
• -x dabei x > 999: Diese werden nicht als Patchtags interpretiert; stattdessen wird das gesamte Suffix als Teil des ursprünglichen Tags behandelt. (Beispiel: ubuntu:jammy-20240530 wird als ursprüngliches Tag betrachtet, kein gepatchtes Tag.) Dies bedeutet, dass beim versehentlichen Anhängen eines neuen Tags, das mit -1 endet, an -999, das kontinuierliche Patchen es wie ein gepatchtes Bild behandelt. Wir empfehlen Ihnen, Tags, die Sie mit dem Suffix -1 versehen möchten, nicht zu -999 zu verschieben. Wenn -999 Versionen eines gepatchten Images betroffen sind, gibt das fortlaufende Patching einen Fehler zurück.

Unverankertes Tagging

Funktionsweise:

Ein einzelnes änderbares Tag -patched wird immer auf die neueste gepatchte Version Ihres Abbildes verweisen. Wenn Ihr Basisimagetag beispielsweise lautet python:3.11, erstellt der erste Patch python:3.11-patched. Bei jedem nachfolgenden Patch wird das -patched Tag automatisch aktualisiert, um auf die neueste gepatchte Version zu verweisen.

Was sollte ich verwenden?

Inkrementelle (Standard): Ideal für Umgebungen, in denen Auditierbarkeit und Rollbacks wichtig sind, da jeder neue Patch eindeutig mit einem eindeutigen Tag identifiziert wird.

Gleitend: Ideal, wenn Sie einen einzelnen Zeiger auf den neuesten Patch für Ihre CI/CD-Pipelines bevorzugen. Verringert die Komplexität, indem die Notwendigkeit entfernt wird, Verweise in nachgeschalteten Anwendungen pro Patch zu aktualisieren, aber die strikte Versionsverwaltung wird geopfert, wodurch es schwierig ist, ein Rollback auszuführen.

Nächste Schritte

Einrichten des kontinuierlichen Patchings