Begrepp: Kontinuerlig korrigering i Azure Container Registry

Azure Container Registrys funktion för kontinuerlig uppdatering automatiserar identifiering och reparation av säkerhetsproblem på operativsystemnivå i containeravbildningar. Genom att schemalägga regelbundna genomsökningar med Trivy och tillämpa säkerhetskorrigeringar med Hjälp av Copa kan du underhålla säkra, up-to-date-avbildningar i registret – utan att kräva åtkomst till källkod eller byggpipelines. Anpassa schema- och målavbildningarna fritt för att hålla din Azure Container Registry-miljö (ACR) säker och kompatibel

Användningsfall

Här följer några scenarier för användning av fortlöpande uppdateringar:

• Framtvinga containersäkerhet och -hygien: Kontinuerlig korrigering gör det möjligt för användare att snabbt åtgärda operativsystemets container-CVE:er (Vanliga sårbarheter och exponeringar) utan att helt behöva bygga om från överordnad.
• Användningshastighet: Kontinuerlig uppdatering tar bort beroendet av överordnade uppdateringar för specifika avbildningar genom att paket uppdateras automatiskt. Sårbarheter kan uppstå varje dag, medan populära distributörer av bilder kanske bara släpper en ny version en gång i månaden. Med kontinuerlig korrigering kan du se till att containeravbildningar i registret korrigeras så snart den senaste uppsättningen säkerhetsproblem i operativsystemet har identifierats.

Prissättning

Kontinuerlig korrigering fungerar under en förbrukningsmodell. Varje patch använder beräkningsresurser, vilket debiteras enligt standardpriset för ACR Task på 0,0001 USD/sekund för uppgift som körs. Mer information finns på prissättningssidan för ACR.

Förhandsversionsbegränsningar

Kontinuerlig uppdatering är för närvarande i offentlig förhandsversion. Följande begränsningar gäller:

• Windows-baserade containeravbildningar stöds inte.
• Endast säkerhetsrisker på "OS-nivå" som kommer från systempaket kommer att korrigeras. Detta inkluderar systempaket i containeravbildningen som hanteras av en operativsystemets pakethanterare, till exempel "apt" och "yum". Sårbarheter som kommer från programpaket, till exempel paket som används av programmeringsspråk som Go, Python och NodeJS, kan inte korrigeras.
• EOSL-avbildningar (End of Service Life) stöds inte av kontinuerlig uppdatering. EOSL-avbildningar refererar till bilder där det underliggande operativsystemet inte längre erbjuder uppdateringar, säkerhetskorrigeringar och teknisk support. Exempel är avbildningar baserade på äldre operativsystemversioner som Debian 8 och Fedora 28. EOSL-avbildningar utelämnas från uppdateringen trots att de innehåller sårbarheter – det rekommenderade tillvägagångssättet är att uppgradera det underliggande operativsystemet till en version som stöds.
• Multi-arkitekturavbilder kommer inte att stödjas.
• En gräns på 100 bilder tillämpas för kontinuerlig korrigering
• Kontinuerlig korrigering är inte kompatibel med ABAC-aktiverade register (attributbaserad åtkomstkontroll) och med lagringsplatser med PTC-regler (Pull Through Cache) aktiverade.
• Azure-prenumerationer på kostnadsfri utvärderingsversion med kostnadsfria krediter stöds inte eftersom kostnadsfria utvärderingskonton saknar åtkomst till ACR Task.

Viktiga begrepp

Eftersom kontinuerlig korrigering i ACR skapar en ny avbildning per korrigering förlitar sig ACR på en taggkonvention för version och identifierar korrigerade bilder. De två huvudsakliga metoderna är inkrementella och flytande.

Inkrementell taggning

Så här fungerar det:

Varje ny korrigering ökar ett numeriskt suffix (till exempel -1, -2, osv.) på den ursprungliga taggen. Till exempel, om basavbildningen är python:3.11 skapar den första korrigeringen python:3.11-1, och en andra korrigering på samma bastagg skapar python:3.11-2.

Särskilda suffixregler:

• -1 till -999: Dessa betraktas som korrigeringstaggar.
• -x where x > 999: Dessa tolkas inte som korrigeringstaggar. I stället behandlas hela suffixet som en del av den ursprungliga taggen. (Exempel: ubuntu:jammy-20240530 anses vara en ursprunglig tagg, inte en korrigerad tagg.) Det innebär att om du skickar en ny tagg som slutar -1 med -999 av misstag behandlar Kontinuerlig korrigering den som en korrigerad bild. Vi rekommenderar att du undviker att skicka taggar som du vill korrigera med suffixet -1 till -999. Om -999 versioner av en korrigerad avbildning träffas returnerar kontinuerlig patchning ett fel.

Flytande taggning

Så här fungerar det:

En enda föränderlig tagg, -patched, refererar alltid till den senaste patchade versionen av din bild. Om basbildtaggen till exempel är python:3.11, skapar den första korrigeringen python:3.11-patched. Med varje efterföljande korrigering uppdateras taggen -patched automatiskt så att den pekar på den senaste korrigerade versionen.

Vilken ska jag använda?

Inkrementell (standard): Perfekt för miljöer där granskning och återställningar är viktiga, eftersom varje ny korrigering tydligt identifieras med en unik tagg.

Flyttande: Perfekt om du föredrar en enda pekare till den senaste korrigeringen för dina CI/CD-pipelines. Minskar komplexiteten genom att ta bort behovet av att uppdatera referenser i nedströms applikationer per uppdatering, men offrar strikt versionshantering, vilket gör det svårt att göra en återgång.

Nästa steg