Wat is het ondertekenen van containerimages (Docker)?

Container image signing is het proces waarbij een cryptografische handtekening aan een containerimage wordt toegevoegd, zodat iedereen die de image downloadt, kan controleren wie deze heeft gepubliceerd en kan bevestigen dat deze niet is gewijzigd sinds de image is gebouwd. Het is een vorm van codeondertekening die wordt toegepast op de OCI-images die in Docker en Kubernetes draaien.

Het digitaal ondertekenen van containerimages voegt een digitale handtekening toe aan een Docker- of OCI-image, gekoppeld aan de inhoudsdigest van de image. Hierdoor kan een registry of Kubernetes-cluster de herkomst en integriteit van de image verifiëren voordat deze wordt uitgevoerd. De ondertekening bewijst dat de image afkomstig is van uw build-pipeline en niet is gemanipuleerd in de registry of tijdens het transport. De meest gebruikte tools zijn Sigstore Cosign en Notary v2 (Notation), die handtekeningen als aparte artefacten in de registry opslaan, samen met de image.

Key Takeaways

• Bij het ondertekenen van een containerimage wordt een cryptografische handtekening gekoppeld aan de inhoud ervan, zodat gebruikers kunnen controleren wie de image heeft gemaakt en of deze niet is gewijzigd.
• Bij moderne ondertekening wordt de handtekening niet in de afbeelding zelf ingebed. De handtekening wordt als een apart artefact opgeslagen in het OCI-register, dat verwijst naar de afbeeldingssamenvatting.
• De belangrijkste tools zijn Sigstore Cosign (ontwikkelaarsvriendelijk, ondersteunt zowel sleutelloze OIDC-ondertekening als ondertekening met sleutels) en Notary v2 / Notation (gestandaardiseerd, PKI- en truststore-georiënteerd, de voorkeurspartner voor bedrijven). Docker Content Trust (DCT) is de oudere aanpak en wordt uitgefaseerd voor officiële Docker-images.
• Onderteken altijd de hashtag van de afbeelding (de @sha256-referentie), nooit een veranderlijke tag zoals :latest, omdat tags naar andere content kunnen verwijzen.
• Verificatie wordt tijdens de implementatie afgedwongen via Kubernetes Toegangscontrolemechanismen zorgen ervoor dat niet-ondertekende of onbetrouwbare afbeeldingen worden geblokkeerd voordat ze worden uitgevoerd.

Waarom het ondertekenen van containers met een afbeelding belangrijk is

Containers zijn de standaardeenheid voor moderne software-implementatie, en een containerimage doorloopt vele stappen tussen build en runtime: een CI-systeem bouwt de image, een registry slaat deze op, een orchestrator haalt de image op en een node voert deze uit. Op elk van deze punten kan een aanvaller die een image kan vervangen of wijzigen, zijn code in uw omgeving uitvoeren. Het ondertekenen van containerimages dicht deze barrière door manipulatie detecteerbaar te maken.

Dit is hetzelfde probleem in de toeleveringsketen dat de SolarWinds-aanval zo schadelijk maakte, maar dan toegepast op containers. Een digitale handtekening bewijst twee dingen die een register alleen niet kan: herkomst, wat betekent dat de image daadwerkelijk uit uw pipeline komt, en integriteit, wat betekent dat de bytes die u hebt ondertekend ook daadwerkelijk de bytes zijn die worden uitgevoerd. Zonder ondertekening vertelt een register u alleen dat een image bestaat, niet dat het de image is die u vertrouwt.

Hoe werkt het ondertekenen van containerimages?

Containerondertekening volgt hetzelfde patroon met publieke sleutels als codeondertekening , aangepast aan de manier waarop containerregisters gegevens opslaan.

1. Bouw en publiceer via een samenvatting: Je pipeline bouwt de image en uploadt deze naar een register. De image wordt geïdentificeerd door een onveranderlijke inhoudsdigest (een sha256-hash van de inhoud), niet alleen door een veranderlijke tag.
2. Onderteken de nieuwsbrief: Een ondertekeningsprogramma hasht het afbeeldingsmanifest en ondertekent het met een privésleutel, waardoor een handtekening ontstaat die exact aan die hash is gekoppeld. Het is essentieel om de hash te ondertekenen, en niet de tag, omdat tags later naar andere content kunnen verwijzen.
3. Bewaar de handtekening in het register: De handtekening wordt geüpload naar hetzelfde register als een apart OCI-artefact dat verwijst naar de afbeeldingsdigest. De handtekening bevindt zich naast de afbeelding, niet erin.
4. Controleer dit voordat u het uitvoert: Bij de implementatie haalt een verificator de handtekening op, controleert deze aan de hand van de vertrouwde publieke sleutel of identiteit en bevestigt dat de hash overeenkomt. Als de verificatie mislukt, wordt de image afgewezen.

Een cruciaal detail: omdat de handtekening gekoppeld is aan de hash, beschermt deze de exacte inhoud van de afbeelding. Als zelfs maar één byte van de afbeelding verandert, verandert de hash en komt de handtekening niet meer overeen. Dit maakt manipulatie detecteerbaar.

De belangrijkste tools voor het ondertekenen van containers

Er zijn drie dominante benaderingen, en weten welke welke is, voorkomt veel verwarring.

Sigstore Cosign

Cosign, onderdeel van het Sigstore-project van de Linux Foundation, is de meest gebruikte tool voor het ondertekenen van containers. Het ondersteunt twee modi. Bij ondertekening op basis van sleutels wordt een privésleutel gebruikt die u beheert. Deze sleutel kan zich bevinden in een bestand, een cloud-KMS of een HSM die toegankelijk is via PKCS#11.

Keyless signing maakt gebruik van kortstondige certificaten die worden uitgegeven door Sigstore's Fulcio-certificeringsinstantie op basis van een OIDC-identiteit (zoals een GitHub-, Google- of Microsoft-account), waarbij de ondertekeningsgebeurtenis wordt vastgelegd in het openbare transparantielogboek van Rekor. Cosign slaat handtekeningen op in het OCI-register samen met de image en integreert naadloos met CI-systemen en Kubernetes-toegangscontrole.

Notaris v2 (Notatie)

Notation is de CLI voor Notary v2, een CNCF-project. Het legt de nadruk op een gestandaardiseerd handtekeningformaat en een PKI- en vertrouwensopslagmodel, waarbij beheerders via een vertrouwensbeleid bepalen welke ondertekeningsidentiteiten worden vertrouwd. Dit ontwerp is aantrekkelijk voor bedrijven die al hun eigen certificeringsinstanties beheren en leverancierondersteunde, specificatiegedreven ondertekening willen. Notation wordt aanbevolen in de richtlijnen voor beheerde Kubernetes van Microsoft (AKS) en Amazon (EKS).

Docker Content Trust (verouderd)

Docker Content Trust (DCT), gebouwd op het Update Framework en uitgebracht in 2015, is het Notary v1-project geworden. Het is het oorspronkelijke mechanisme voor het ondertekenen van containers, maar het is nu verouderd. Docker heeft aangegeven dat het DCT uitfaseert voor officiële Docker-images en adviseert uitgevers om over te stappen naar een nieuwer systeem zoals Sigstore of Notation. Registryplatformen volgen dit voorbeeld; Harbor heeft bijvoorbeeld de ondersteuning voor Notary v1 in versie 2.9 afgeschaft en gebruikt in plaats daarvan Cosign of Notation. Nieuwe implementaties zouden niet langer standaard op DCT moeten vertrouwen.

Gereedschap	Vertrouwensmodel	Beste pasvorm
Cosign (Sigstore)	Sleutelloze OIDC via Fulcio en Rekor, of zelfbeheerde sleutels.	Ontwikkelaarsvriendelijke ondertekening, CI/CD, open source, brede registerondersteuning
Notatie (Notaris v2)	PKI en vertrouwensopslag, gestandaardiseerd handtekeningformaat	Ondernemingen met bestaande PKI; AKS- en EKS-richtlijnen
Docker Content Trust (Notary v1)	TUF-gebaseerde sleutels per tag	Alleen Legacy; aangezien u met pensioen bent, kunt u overstappen op een ander plan.

Beste werkwijzen voor het ondertekenen van containerimages

• Onderteken de samenvatting, niet het label: Koppel handtekeningen aan de onveranderlijke sha256-hash. Een tag zoals :latest kan naar andere inhoud verwijzen, dus het ondertekenen van een tag bewijst vrijwel niets.
• Bescherm de ondertekeningssleutels in hardware: Langdurig bewaarde ondertekeningssleutels moeten worden opgeslagen in een HSM of een hardwarematig KMS, niet op een ontwikkelaarslaptop of de schijf van een CI-runner, zodat een gecompromitteerde buildhost ze niet kan stelen.
• Voer verificatie uit bij de ingang: Gebruik een Kubernetes admission controller of policy engine om niet-ondertekende of onbetrouwbare images te blokkeren tijdens de implementatie, zodat ondertekening niet slechts een advies is.
• Verifieer de identiteit, niet alleen de aanwezigheid: Controleer of een afbeelding is ondertekend door een identiteit die u vertrouwt, en niet alleen of er een handtekening aanwezig is. Een handtekening van een onbekende sleutel is niet betrouwbaar.
• Voeg herkomstgegevens en SBOM's toe: Moderne gereedschappen kunnen certificaten van herkomst van de constructie en een bijbehorende bevestiging bevatten. Software stuklijst naar dezelfde samenvatting, waardoor de bewijsketen wordt versterkt.
• Centraliseer sleutels en audits: Gebruik een centrale ondertekeningsservice, zodat elke ondertekeningshandeling wordt geverifieerd, geregistreerd en traceerbaar is, in plaats van verspreid over verschillende teams met hun eigen sleutels.

De kloof binnen de onderneming: sleutelmanagement

De ondertekeningstools lossen de technische aspecten van het genereren en verifiëren van een handtekening op. Ze bieden op zichzelf geen oplossing voor het beheer van bedrijfssleutels. In de praktijk is dat waar containerondertekeningsprogramma's slagen of falen.

Als ondertekeningssleutels zich op ontwikkelaarsmachines of CI-runners bevinden, zijn ze blootgesteld aan precies het soort beveiligingslek dat ondertekening juist moet voorkomen. Als elk team zijn eigen sleutels beheert, is er geen centraal controletraject van wie wat heeft ondertekend, geen consistent beleid en geen eenvoudige manier om sleutels te vernieuwen of in te trekken na een incident. Sleutelloos ondertekenen verschuift het vertrouwen naar een identiteitsprovider en een openbaar transparantielogboek, wat geschikt is voor open-sourceprojecten, maar niet aansluit bij de compliance- en privacybehoeften van elke onderneming.

De bedrijfsvereiste is om de ondertekeningssleutels van containers in hardware op te slaan, te bepalen wie mag ondertekenen en elke bewerking te loggen, zonder de ontwikkelaars te vertragen.

Hoe encryptieconsultancy kan helpen

CodeSign Secure van Encryption Consulting brengt sleutelbeheer op bedrijfsniveau naar het ondertekenen van containerimages. Het bewaart ondertekeningssleutels in een FIPS 140-2 Level 2 HSM in plaats van op ontwikkelmachines of CI-runners, integreert met de workflow voor het ondertekenen van containers zodat images worden ondertekend met hardwarebeveiligde sleutels, en handhaaft wie bevoegd is om te ondertekenen, terwijl elke bewerking wordt gelogd voor auditdoeleinden.

Omdat CodeSign Secure het ondertekenen van bestanden centraliseert voor alle typen artefacten, wordt hetzelfde platform dat uw Windows-, Java- en firmware-ondertekening beschermt ook gebruikt voor uw containerimages. Dit biedt beveiligingsteams één consistent beleid en auditspoor in plaats van een apart, ongereguleerd proces voor containers. Ondersteund door ISO/IEC 27001:2022 en SOC 2-gecertificeerde werkwijzen.

Veelgestelde Vragen / FAQ

Wat is het ondertekenen van containerimages?

Container image signing voegt een cryptografische handtekening toe aan een containerimage (OCI), zodat iedereen die de image downloadt, kan controleren wie deze heeft gepubliceerd en kan bevestigen dat deze niet is gewijzigd sinds de build. De handtekening is gekoppeld aan de content digest van de image en wordt als een apart artefact in het register opgeslagen. Het is het equivalent van code signing in de containerwereld en beschermt de softwareleveringsketen tussen build en implementatie.

Wat is het verschil tussen Cosign, Notation en Docker Content Trust?

Cosign, onderdeel van Sigstore, is een ontwikkelaarsvriendelijke tool die zowel sleutelloze OIDC-ondertekening als zelfbeheerde sleutels ondersteunt en veel wordt gebruikt in CI/CD. Notation, de CLI voor Notary v2, is een CNCF-project met een gestandaardiseerd handtekeningformaat en een PKI-vertrouwensmodel dat populair is bij bedrijven en wordt aanbevolen voor AKS en EKS. Docker Content Trust (Notary v1) is het oorspronkelijke, op TUF gebaseerde mechanisme uit 2015; het is nu verouderd en wordt uitgefaseerd voor officiële Docker-images.

Moet ik het afbeeldingslabel of het samenvattingsrapport ondertekenen?

Onderteken altijd de digest, de onveranderlijke @sha256-referentie, nooit een veranderlijke tag zoals :latest. Tags zijn verwijzingen die op elk moment naar andere inhoud kunnen verwijzen, dus een handtekening op een tag bewijst vrijwel niets over wat er daadwerkelijk wordt uitgevoerd. Een handtekening die aan de digest is gekoppeld, beschermt de exacte bytes van de afbeelding: als een byte verandert, verandert de digest en is de handtekening niet langer geldig, wat manipulatie detecteerbaar maakt.

Wordt Docker Content Trust nog steeds aanbevolen?

Nee. Docker Content Trust (DCT), gebaseerd op Notary v1, is verouderd. Docker heeft aangegeven dat DCT wordt uitgefaseerd voor officiële Docker-images en adviseert uitgevers over te stappen op een nieuwere oplossing voor ondertekening en verificatie, zoals Sigstore of Notation. Registryplatformen volgen hetzelfde pad; Harbor heeft bijvoorbeeld Notary v1 in versie 2.9 afgeschaft. Bestaande DCT-gebruikers moeten een migratie plannen en nieuwe implementaties zouden in plaats daarvan moeten standaardiseren op Cosign of Notation.

Hoe wordt een ondertekende containerimage geverifieerd tijdens de implementatie?

Verificatie wordt doorgaans afgedwongen door een Kubernetes admission controller of policy engine die image-implementaties onderschept. Wanneer een pod wordt gepland, haalt de controller de handtekening van de image op uit het register, controleert deze aan de hand van de vertrouwde publieke sleutel of identiteit en bevestigt dat de handtekening overeenkomt met de hash van de image. Als de image niet ondertekend is of ondertekend is door een niet-vertrouwde identiteit, wordt deze door de controller afgewezen, zodat alleen geverifieerde images in het cluster worden uitgevoerd.

Waar moeten de ondertekeningssleutels van containers worden opgeslagen?

Langdurig geldige ondertekeningssleutels voor containers moeten worden opgeslagen in een Hardware Security Module (HSM) of een hardwarematige sleutelbeheerservice, en niet op laptops van ontwikkelaars of CI-runner-schijven, precies de systemen die een aanvaller zou willen aanvallen. Door sleutels in hardware op te slaan, kan een gecompromitteerde buildhost de privésleutel niet stelen. Bedrijven gebruiken doorgaans een gecentraliseerde ondertekeningsservice die sleutels in een HSM bewaart, bepaalt wie mag ondertekenen en een auditlogboek van elke ondertekeningsbewerking genereert.

Integreer Enterprise Key Management in uw containerondertekening.

Software voor het ondertekenen van code genereert digitale handtekeningen. Bedrijfsprogramma's hebben deze handtekeningen nodig, ondersteund door hardwarebeveiligde sleutels, afgedwongen beleid en een volledig auditspoor. Ontdek CodeSign Secure om uw containerimages te ondertekenen met HSM-beveiligde sleutels, gecentraliseerd beleid en audit, in combinatie met de rest van uw codeondertekening.