Vad är containeravbildningssignering (Docker-avbildning)?

Signering av containeravbildningar är metoden att koppla en kryptografisk signatur till en containeravbildning så att alla som hämtar den kan verifiera vem som publicerade den och bekräfta att den inte har ändrats sedan den skapades. Det är kodsignering som tillämpas på OCI-avbildningar som körs i Docker och Kubernetes.

Signering av containeravbildningar kopplar en digital signatur till en Docker- eller OCI-avbildning, kopplad till avbildningens innehållssammanfattning, så att ett register- eller Kubernetes-kluster kan verifiera avbildningens ursprung och integritet innan den körs. Signering bevisar att avbildningen kom från din byggpipeline och inte manipulerades i registret eller under överföring. De vanliga verktygen är Sigstore Cosign och Notary v2 (Notation), som lagrar signaturer som separata artefakter i registret tillsammans med avbildningen.

Key Takeaways

• Signering av containeravbildningar kopplar en kryptografisk signatur till en containeravbildning, kopplad till dess innehållssammanfattning, så att konsumenter kan verifiera vem som byggde den och att den inte har modifierats.
• Modern signering bäddar inte in signaturen i bilden. Signaturen lagras som en separat artefakt i OCI-registret som refererar till bildsammanfattningen.
• De viktigaste verktygen är Sigstore Cosign (utvecklarvänligt, stöder nyckelfri OIDC-signering och nyckelbaserad signering) och Notary v2 / Notation (standardiserat, PKI- och trust-store-orienterat, föredras för företag). Docker Content Trust (DCT) är den äldre metoden och pensioneras för Docker Official Images.
• Signera alltid bildsammanfattningen (referensen @sha256), aldrig en modifierbar tagg som :latest, eftersom taggar kan pekas om till olika innehåll.
• Verifiering verkställs vid driftsättning via Kubernetes åtkomstkontroller, så osignerade eller otillförlitliga bilder blockeras innan de körs.

Varför containeravbildningssignering är viktigt

Containrar är standardenheten för modern programvarudistribution, och en containeravbildning passerar genom många händer mellan bygg- och körtid: ett CI-system bygger den, ett register lagrar den, en orkestrator hämtar den och en nod kör den. Vid vilken som helst av dessa punkter kan en angripare som kan ersätta eller modifiera en avbildning köra sin kod inuti din miljö. Signering av containeravbildningar täcker den luckan genom att göra manipulering detekterbar.

Detta är samma problem i leveranskedjan som gjorde SolarWinds-attacken så skadlig, tillämpat på containrar. En signatur bevisar två saker som ett register ensamt inte kan: proveniens, vilket innebär att bilden verkligen kom från din pipeline, och integritet, vilket innebär att exakt de byte du signerade är exakt de byte som körs. Utan signering berättar ett register bara att en bild existerar, inte att det är den du litar på.

Så fungerar signering av containerbilder

Containersignering följer samma mönster för offentlig nyckel som all kodsignering , anpassat till hur containerregister lagrar data.

1. Bygg och push genom digest: Din pipeline bygger avbildningen och skickar den till ett register. Avbildningen identifieras av en oföränderlig innehållssammanfattning (en sha256-hash av dess innehåll), inte bara av en föränderlig tagg.
2. Signera sammanfattningen: Ett signeringsverktyg hashar bildmanifestet och signerar det med en privat nyckel, vilket skapar en signatur som är kopplad till exakt den sammanfattningen. Att signera sammanfattningen, inte taggen, är avgörande, eftersom taggar senare kan pekas om till annat innehåll.
3. Lagra signaturen i registret: Signaturen laddas upp till samma register som en separat OCI-artefakt som refererar till bildsammanfattningen. Signaturen finns bredvid bilden snarare än inuti den.
4. Verifiera innan du kör: Vid distributionen hämtar en verifierare signaturen, kontrollerar den mot den betrodda publika nyckeln eller identiteten och bekräftar sammanfattningarna. Om verifieringen misslyckas avvisas bilden.

En avgörande detalj: eftersom signaturen är bunden till digestet skyddar den det exakta bildinnehållet. Om så bara en byte av bilden ändras, ändras digestet och signaturen matchar inte längre. Det är detta som gör manipulering detekterbar.

De viktigaste verktygen för containersignering

Tre tillvägagångssätt dominerar, och att veta vilket som är vilket förhindrar mycket förvirring.

Sigstore Cosign

Cosign, en del av Linux Foundations Sigstore-projekt, är det mest använda verktyget för containersignering. Det stöder två lägen. Nyckelbaserad signering använder en privat nyckel som du hanterar, vilken kan finnas i en fil, ett moln-KMS eller en HSM som nås via PKCS#11.

Nyckelfri signering använder kortlivade certifikat utfärdade av Sigstores Fulcio-certifikatutfärdare baserat på en OIDC-identitet (t.ex. ett GitHub-, Google- eller Microsoft-konto), där signeringshändelsen registreras i Rekors offentliga transparenslogg. Cosign lagrar signaturer i OCI-registret tillsammans med bilden och integreras snyggt med CI-system och Kubernetes åtkomstkontroll.

Notarie v2 (Notation)

Notation är CLI för Notary v2, ett CNCF-projekt. Det betonar ett standardiserat signaturformat och en PKI- och trust-store-modell, där administratörer definierar vilka signeringsidentiteter som är betrodda genom en betrodd policy. Denna design tilltalar företag som redan driver sina egna certifikatutfärdare och vill ha leverantörsstödd, specifikationsdriven signering. Notation rekommenderas i de hanterade Kubernetes-riktlinjerna från Microsoft (AKS) och Amazon (EKS).

Docker Content Trust (äldre)

Docker Content Trust (DCT), byggt på The Update Framework och släppt 2015, blev Notary v1-projektet. Det är den ursprungliga containersigneringsmekanismen, men den är nu ett äldre system. Docker har meddelat att de pensionerar DCT för Docker Official Images och råder utgivare att migrera till ett nyare system som Sigstore eller Notation. Registerplattformar följer efter; till exempel har Harbor föråldrat stödet för Notary v1 i version 2.9 och använder Cosign eller Notation istället. Nya distributioner bör inte standardiseras på DCT.

Verktyget	Förtroendemodell	Bästa passform
Cosign (Sigstore)	Nyckellös OIDC via Fulcio och Rekor, eller självhanterade nycklar	Utvecklarvänlig signering, CI/CD, öppen källkod, brett registerstöd
Notation (Notarius v2)	PKI och förtroendelagring, standardiserat signaturformat	Företag med befintlig PKI; AKS- och EKS-vägledning
Docker Content Trust (Notarius v1)	TUF-baserade nycklar per tagg	Endast äldre; pensionerad, planera migrering

Bästa praxis för signering av containeravbildningar

• Signera sammanfattningen, inte taggen: Bind signaturer till den oföränderliga sha256-sammanfattningen. En tagg som :latest kan pekas om till annat innehåll, så att signera en tagg bevisar nästan ingenting.
• Skydda signeringsnycklar i hårdvara: Långlivade signeringsnycklar bör finnas i en HSM eller en hårdvarubaserad KMS, inte på en utvecklarbärbar dator eller en CI Runner-disk, så att en komprometterad byggvärd inte kan stjäla dem.
• Verkställ verifiering vid antagning: Använd en Kubernetes-åtkomstkontrollant eller policymotor för att blockera osignerade eller otillförlitliga avbildningar vid distributionstillfället, så att signering inte bara är rådgivande.
• Verifiera identitet, inte bara närvaro: Kontrollera att en bild är signerad av en identitet du litar på, inte bara att det finns en signatur. En signatur från en okänd nyckel är inte tillförlitlig.
• Bifoga proveniens och SBOM:er: Moderna verktyg kan bifoga intyg om byggproveniens och en Programvarulista till samma sammanfattning, vilket stärker spårbarhetskedjan.
• Centralisera nycklar och granska: Använd en central signeringstjänst så att varje signeringsåtgärd autentiseras, loggas och granskas, snarare än att den är utspridd över team med egna nycklar.

Företagsklyftan: Nyckelhantering

Signeringsverktygen löser mekanismerna för att skapa och verifiera en signatur. De löser inte, i sig själva, företagsnyckelhantering. I praktiken är det där containersigneringsprogram lyckas eller misslyckas.

Om signeringsnycklar finns på utvecklarmaskiner eller CI-körningar utsätts de för precis den kompromiss i leveranskedjan som signering är avsedd att förhindra. Om varje team hanterar sina egna nycklar finns det ingen central revisionslogg för vem som signerat vad, ingen konsekvent policy och inget enkelt sätt att rotera eller återkalla nycklar efter en incident. Nyckellös signering flyttar förtroendet till en identitetsleverantör och en offentlig transparenslogg, vilket passar öppen källkodsprojekt men inte uppfyller alla företags behov av efterlevnad och integritet.

Företagskravet är att förvara containersigneringsnycklar i hårdvaran, säkerställa vem som får signera och logga varje operation, utan att sakta ner utvecklarna.

Hur krypteringskonsulting hjälper

Encryption Consultings CodeSign Secure ger företagsnyckelhantering till containeravbildningssignering. Den håller signeringen av nycklar i en FIPS 140-2 Level 2 HSM istället för på utvecklarmaskiner eller CI-körmaskiner, integrerar med containersigneringsarbetsflödet så att avbildningar signeras mot hårdvaruskyddade nycklar och tvingar fram vem som får signera medan varje operation loggas för granskning.

Eftersom CodeSign Secure centraliserar signering över olika artefakttyper, styr samma plattform som skyddar din Windows-, Java- och firmware-signering även dina containeravbildningar, vilket ger säkerhetsteam en enhetlig policy och revisionslogg snarare än en separat, ostyrd process för containrar. Stöds av ISO/IEC 27001:2022 och SOC 2-certifierade metoder.

Vanliga frågor om partihandel med mat och dryck

Vad är containeravbildningssignering?

Signering av containeravbildningar kopplar en kryptografisk signatur till en containeravbildning (OCI) så att alla som hämtar den kan verifiera vem som publicerade den och bekräfta att den inte har ändrats sedan den skapades. Signaturen är kopplad till avbildningens innehållssammanfattning och lagras i registret som en separat artefakt. Det är containervärldens motsvarighet till kodsignering och den skyddar programvaruleveranskedjan mellan byggnation och distribution.

Vad är skillnaden mellan Cosign, Notation och Docker Content Trust?

Cosign, en del av Sigstore, är ett utvecklarvänligt verktyg som stöder både nyckelfri OIDC-signering och självhanterade nycklar, och används flitigt i CI/CD. Notation, CLI för Notary v2, är ett CNCF-projekt med ett standardiserat signaturformat och en PKI-förtroendelagringsmodell som föredras av företag och rekommenderas för AKS och EKS. Docker Content Trust (Notary v1) är den ursprungliga, TUF-baserade mekanismen från 2015; den är nu en äldre version och pensioneras för Docker Official Images.

Ska jag signera bildtaggen eller sammanfattningen?

Signera alltid digestet, den oföränderliga @sha256-referensen, aldrig en föränderlig tagg som :latest. Taggar är pekare som kan pekas om till annat innehåll när som helst, så en signatur på en tagg bevisar nästan ingenting om vad som faktiskt körs. En signatur som är bunden till digestet skyddar de exakta bildbytena: om någon byte ändras ändras digestet och signaturen verifieras inte längre, vilket är det som gör manipulering detekterbar.

Rekommenderas Docker Content Trust fortfarande?

Nej. Docker Content Trust (DCT), baserat på Notary v1, är ett äldre system. Docker har meddelat att de pensionerar DCT för Docker Official Images och råder utgivare att byta till en nyare signerings- och verifieringslösning som Sigstore eller Notation. Registerplattformar följer samma väg; till exempel har Harbor föråldrat Notary v1 i version 2.9. Befintliga DCT-användare bör planera en migrering, och nya distributioner bör standardiseras på Cosign eller Notation istället.

Hur verifieras en signerad containeravbildning vid distribution?

Verifiering verkställs vanligtvis av en Kubernetes-admissionskontrollant eller policymotor som avlyssnar avbildningsdistributioner. När en pod schemaläggs hämtar kontrollanten avbildningens signatur från registret, kontrollerar den mot den betrodda publika nyckeln eller identiteten och bekräftar att signaturen matchar avbildningssammanfattningen. Om avbildningen är osignerad eller signerad av en obetrodd identitet avvisar kontrollanten den, så endast verifierade avbildningar körs någonsin i klustret.

Var ska containersigneringsnycklar förvaras?

Långlivade containersigneringsnycklar bör lagras i en Hardware Security Module (HSM) eller en hårdvarubaserad nyckelhanteringstjänst, inte på utvecklarbärbara datorer eller CI Runner-diskar, vilket är exakt de system en angripare skulle rikta in sig på. Att lagra nycklar i hårdvara innebär att en komprometterad byggvärd inte kan exfiltrera den privata nyckeln. Företag använder vanligtvis en centraliserad signeringstjänst som förvarar nycklar i en HSM, kontrollerar vem som får signera och skapar en granskningslogg för varje signeringsoperation.

Få Enterprise Key Management till din containersignering

Signeringsverktyg producerar signaturer. Företagsprogram behöver dessa signaturer backade upp av hårdvaruskyddade nycklar, en tvingande policy och en fullständig revisionslogg. Utforska CodeSign Secure för att signera dina containeravbildningar mot HSM-skyddade nycklar med centraliserad policy och revision, tillsammans med resten av din kodsignering.