Elke containerimage die je uitvoert, is een stukje software dat je blindelings vertrouwt, tenzij je iets hebt gedaan om het te verifiëren. Het is afkomstig van een registry, heeft een build-pipeline doorlopen, en ergens in dat proces had iedereen met toegang het kunnen vervangen door iets anders. Containerondertekening is de manier om die kloof te dichten. Je voegt een cryptografische handtekening toe aan een image, en je cluster weigert alles uit te voeren dat geen geldige handtekening heeft.
Lange tijd was dit een prettige bijkomstigheid die beveiligingsbewuste teams wel deden, maar die de rest uitstelde. Dat verandert snel. Regelgeving zoals de Cyber Resilience Act van de EU en frameworks zoals Supply Chain Levels for Software Artifacts (SLSA) , ontwikkeld door Google, plaatsen de integriteit van de toeleveringsketen hoger op de prioriteitenlijst. Voor organisaties die software in containers verzenden, zijn ondertekende images met verplichte verificatie een prioriteit voor 2026 geworden in plaats van een project voor ooit.
Twee tools domineren de discussie: Notation, van het CNCF Notary Project, en Cosign, van het Sigstore-project. Mensen benaderen de keuze vaak als een vergelijking van functionaliteiten. Het is echter nuttiger om het te zien als een keuze tussen twee verschillende vertrouwensmodellen, omdat dat uiteindelijk bepaalt welke het beste bij uw organisatie past.
Wat de twee gereedschappen gemeen hebben
Voordat we naar de verschillen kijken, is het nuttig om de gedeelde basis te zien, want die is groter dan je misschien denkt.
Zowel Notation als Cosign ondertekenen OCI-artefacten, niet alleen containerimages. Beide slaan de handtekening op in uw register als een apart artefact dat aan de image is gekoppeld, met behulp van de OCI 1.1 Referrers API . De handtekening reist dus met de image mee en heeft geen aparte database nodig. Beide verifiëren aan de hand van een digest in plaats van een tag, wat belangrijk is omdat tags kunnen worden verplaatst en een digest niet. En beide maken gebruik van dezelfde handhavingslaag in Kubernetes, dus met welke optie u ook kiest, kunt u implementaties beveiligen op basis van een geldige handtekening.
In feite kunnen de twee naast elkaar bestaan op dezelfde image. Sommige organisaties gebruiken Cosign in hun CI-pipeline voor het gemak en gebruiken Notation voor de formele release-ondertekening. Vervolgens vereisen ze beide handtekeningen voordat er iets wordt geïmplementeerd. De tools sluiten elkaar niet uit. Maar voor de meeste teams die een primaire aanpak kiezen, is het vertrouwensmodel doorslaggevend.
Cosign: Identiteitsgebaseerd, sleutelloos en snel te implementeren
De belangrijkste functie van Cosign is het ondertekenen zonder sleutels, en dat is echt slim bedacht. In plaats van een langdurige ondertekeningssleutel te beheren, authenticeert de ondertekenaar zich via een OIDC-identiteitsprovider, hetzelfde type login dat uw CI-systeem al heeft. Een Sigstore-service genaamd Fulcio geeft een kortstondig X.509-certificaat uit , geldig voor ongeveer 10 minuten, waarmee die identiteit wordt gekoppeld aan een tijdelijk sleutelpaar. Zowel de handtekening als het certificaat worden vastgelegd in een transparantielogboek genaamd Rekor, waardoor een verifieerbaar overzicht ontstaat van wie wanneer heeft ondertekend, zelfs nadat de sleutel is verdwenen.
De aantrekkingskracht is duidelijk. Er is geen ondertekeningssleutel die opgeslagen, geroteerd, beveiligd of verloren kan gaan, omdat de sleutel nooit permanent wordt opgeslagen. Voor een team zonder een dedicated PKI- functie neemt dit het moeilijkste onderdeel van het ondertekenen weg. Cosign biedt bovendien eersteklas ondersteuning voor het toevoegen van SBOM's en SLSA-provenance-attestaties, en het breedste ecosysteem aan Kubernetes-handhavingstools eromheen. Als u een moderne provenance- en attestatiepipeline bouwt en snel vooruit wilt, is Cosign vaak de snelste oplossing.
De keerzijde is het vertrouwensmodel zelf. Sleutelloos ondertekenen koppelt vertrouwen aan een identiteit die is geverifieerd door een externe OIDC-provider, en in de standaardvorm is het afhankelijk van de openbare infrastructuur van Sigstore. Je kunt Fulcio en Rekor zelf hosten om dit in eigen beheer te nemen, maar dat brengt wel degelijk operationeel werk met zich mee. En identiteitsgebaseerd vertrouwen, hoewel krachtig, is iets anders dan het sleutelbewaringsmodel waarop veel compliance-regimes zijn gebaseerd.
Notatie: Enterprise PKI en sleutels die u beheert
Notation hanteert de aanpak die grote bedrijven al decennia gebruiken voor het ondertekenen van code. Je ondertekent met een X.509-certificaat dat is uitgegeven door een certificeringsinstantie die je vertrouwt, meestal je eigen instantie, en de verificatie controleert de handtekening aan de hand van die CA via een vertrouwensbeleid dat je zelf definieert. De handtekeningen gebruiken het COSE-formaat en worden, net als bij Cosign, opgeslagen als OCI-artefacten in het register. Het vertrouwensbeleid van Notation kan nauwkeurig worden afgebakend, tot specifieke registers, repositories of identiteiten, wat geschikt is voor organisaties die behoefte hebben aan gedelegeerde en gesegmenteerde ondertekeningsbevoegdheid.
Wat Notation zo geschikt maakt voor een gereguleerde onderneming, is juist de verankering in uw eigen PKI. De ondertekeningssleutel is een duurzaam bedrijfsmiddel onder uw controle, geen vluchtige referentie gekoppeld aan een externe identiteitsdienst. Het plug-inmodel van Notation integreert met sleutelbeheersystemen en hardwarebeveiligingsmodules, waardoor de ondertekeningssleutel in een HSM kan worden opgeslagen en deze nooit hoeft te verlaten. Voor organisaties met compliance-eisen rondom sleutelbeheer, zoals die van FIPS- validatie of FedRAMP, is deze hardware-ondersteunde, door de organisatie beheerde sleutel vaak het enige model dat aan de eisen voldoet. Het past ook naadloos in omgevingen waar externe openbare infrastructuur geen optie is, maar waar al een interne CA aanwezig is.
De kosten, ten opzichte van sleutelloze Cosign, zijn dat je weer sleutels en een PKI moet beheren. Dat is een aanzienlijke verantwoordelijkheid. Maar voor een organisatie die al een PKI gebruikt , is het geen nieuw werk; het is bestaande functionaliteit die op een nieuwe manier wordt toegepast. Bovendien biedt het een vertrouwensmodel dat direct aansluit op de manier waarop auditors al denken. Intrekking van certificaten wordt afgehandeld via standaard PKI-mechanismen zoals CRL of OCSP . Dit betekent dat een gecompromitteerd ondertekeningscertificaat kan worden ingetrokken en dat afbeeldingen die ermee zijn ondertekend, kunnen worden gemarkeerd of geblokkeerd door het vertrouwensbeleid bij te werken. Dit sluit direct aan op de manier waarop beveiligingsteams binnen een organisatie al omgaan met incidenten met codeondertekeningscertificaten.
Het deel dat mensen vaak vergeten: ondertekenen is maar de helft van het werk.
Hier schuilt de fout die veel ondertekeningspogingen stilletjes ondermijnt. Een handtekening op een image heeft op zichzelf geen effect. Als er in uw cluster niets is dat de handtekening controleert, werkt een niet-ondertekende of gemanipuleerde image net zo makkelijk als een ondertekende. De beveiliging bestaat pas op het moment van controle.
Handhaving in Kubernetes gebeurt via toegangscontrole, en het is nuttig om dit in lagen te bekijken. Een pre-deployment gate, geïmplementeerd met een admission controller zoals Kyverno, de Sigstore Policy Controller of OPA Gatekeeper in combinatie met Ratify, inspecteert elke image vlak voordat deze wordt toegelaten en weigert alles zonder een geldige handtekening die voldoet aan uw beleid.
De runtime kan een tweede laag toevoegen: nieuwere versies van containerd ondersteunen een image-verifier die handtekeningen controleert tijdens het ophalen van een image, voordat deze op een node mag worden uitgevoerd. Daarnaast kan een promotiepoort een geldige handtekening vereisen voordat een image van de stagingomgeving naar de productieregistry wordt verplaatst, en periodieke runtime-audits kunnen bevestigen dat wat al draait nog steeds voldoet aan het huidige beleid.
Deze toegangscontrollers werken over het algemeen in een van de twee modi, en het verschil daartussen is belangrijker dan het lijkt. In de auditmodus geeft een mislukte verificatie een waarschuwing, maar de image wordt alsnog geïmplementeerd. In de handhavingsmodus blokkeert een mislukte verificatie de implementatie volledig. De auditmodus is een goede plek om te beginnen, zodat je kunt zien wat zou worden afgewezen zonder iets te beschadigen, maar de auditmodus biedt geen bescherming.
Het hele doel van ondertekenen is om met vertrouwen de handhavingsmodus te bereiken, en om dat veilig te doen, moet je het beleid geleidelijk uitrollen, naamruimte per naamruimte, met een ondertekeningspipeline die betrouwbaar genoeg is om ervoor te zorgen dat legitieme afbeeldingen nooit falen.
Dit is ook waar de keuze van het instrument de realiteit ontmoet. Welk instrument je ook kiest, de digitale handtekeningen leveren pas waarde op als de handhavingslaag operationeel, afgestemd en betrouwbaar genoeg is om daadwerkelijk blokkeringen uit te voeren. Een digitaal ondertekeningsprogramma dat nooit verder komt dan de auditmodus is pure schijn.
Hoe encryptieconsultancy kan helpen
Het implementeren van containerondertekening die voldoet aan de eisen van CRA en SLSA is deels een kwestie van de juiste tools en deels een kwestie van waar het vertrouwen daadwerkelijk ligt. Voor de meeste bedrijven wijst het antwoord naar ondertekening gebaseerd op een PKI die u beheert, met sleutels die in hardware zijn beveiligd, en dat is precies wat wij doen.
CodeSign Secure , onze oplossing voor het ondertekenen van code, biedt u een gecontroleerd ondertekeningsproces voor uw softwareartefacten, inclusief containerimages, met de beleidscontroles, toegangsbeheer en sleutelbescherming die een Notation-achtige, PKI-ondersteunde aanpak vereist. In plaats van sleutels te ondertekenen die verspreid zijn over CI-runners en ontwikkelmachines, verloopt het ondertekeningsproces via een gecontroleerd systeem met een duidelijk auditspoor. Dit is precies de houding die auditors en supply chain-frameworks verwachten.
Wat Codesign Secure toevoegt aan containerondertekening
In dit artikel is vooral aandacht besteed aan Notation en Cosign, dus het is belangrijk om concreet te beschrijven wat ons eigen platform toevoegt. Een vertrouwensmodel is immers maar zo goed als het ondertekeningsproces dat eromheen is gebouwd. CodeSign Secure is een gecentraliseerd ondertekeningsplatform, speciaal ontwikkeld voor moderne DevOps-omgevingen.
Het integreert met de CI/CD-systemen die de meeste teams al gebruiken, zoals Azure DevOps, Jenkins en GitLab, en het plaatst elke ondertekeningsbewerking achter toegangscontroles en goedkeuringsworkflows, zodat het ondertekeningsproces gereguleerd blijft in plaats van verspreid over verschillende buildagents.
De ondertekeningssleutels blijven opgeslagen in een FIPS 140-2 Level 3 hardwarebeveiligingsmodule en het platform werkt samen met de HSM's die bedrijven al gebruiken, waaronder Entrust nCipher, Thales Luna, Utimaco en Securosys, zowel on-premises als in de cloud. Toegang wordt beheerd via integratie met Microsoft Active Directory en Keycloak, met op rollen gebaseerd toegangsbeheer en aanpasbare workflows.
Het beleid wordt op platformniveau afgedwongen, waardoor niets wordt ondertekend tenzij het voldoet aan de criteria die u definieert, van het certificaattype tot de vereiste goedkeuringen in elke fase. Scheiding van taken is ingebouwd, aangezien een ontwikkelaar een handtekening kan aanvragen, maar een releasemanager of beveiligingsfunctionaris deze moet goedkeuren voordat de handtekening wordt toegepast. Dit elimineert het risico dat een gecompromitteerd account zelfstandig software ondertekent en distribueert.
Omdat het een breed scala aan formaten ondertekent, waaronder Docker-containers en OCI-images, naast firmware-binaries, uitvoerbare bestanden en pakketten, is het net zo geschikt voor het ondertekenen van containers als voor de rest van de ondertekeningsbehoeften van een organisatie, en het kan worden geïntegreerd met gangbare tools zoals Signtool, Jarsigner en JSign.
Het maakt gebruik van client-side hashing en veilige tijdstempels, waardoor handtekeningen geldig blijven, zelfs nadat een certificaat is verlopen. Elk ondertekeningsevenement, inclusief de bijbehorende goedkeuringen en afwijzingen, wordt vastgelegd in auditlogboeken die via OpenTelemetry worden doorgestuurd naar SIEM-tools zoals Grafana, Loki en Splunk. Dit biedt beveiligingsteams het bewijsmateriaal dat supply-chain frameworks verwachten te zien.
Het kan worden uitgevoerd als een volledig beheerde cloudservice met ingebouwde HSM-beveiliging of on-premises met sleutels die worden bewaard in cloud- of on-premise HSM's, zodat het implementatiemodel kan worden afgestemd op uw specifieke behoeften. Het ondertekent ook rechtstreeks op de HSM met post-kwantumalgoritmen, waaronder ML-DSA (Module-Lattice-Based Digital Signature Algorithm) en LMS (Leighton-Micali Signatures), en het ondersteunt dubbele handtekeningen die een klassieke RSA- of ECDSA -handtekening combineren met een post-kwantumhandtekening voor een geleidelijke overgang.
Omdat de betrouwbaarheid van digitale identiteitsondertekening binnen een organisatie afhangt van de certificeringsinstantie die erachter zit, biedt PKI-as-a-Service u een moderne, goed functionerende CA die de ondertekeningscertificaten uitgeeft en beheert die de basis vormen voor uw vertrouwensbeleid, zonder dat u zelf die infrastructuur hoeft op te bouwen en te onderhouden. Dit is de basis van vertrouwen waartegen een Notation-implementatie zich verifieert, en een correcte implementatie hiervan maakt de hele keten geloofwaardig.
Om de ondertekeningssleutels zelf te beschermen, houdt HSM-as-a-Service ze geïsoleerd in een hardwarematige beveiligingsmodule. Hierdoor kan een ondertekeningssleutel niet van een buildserver worden gekopieerd of uit een pipeline worden gehaald. Voor organisaties met FIPS- of FedRAMP-verplichtingen met betrekking tot sleutelbeheer zijn hardwarematig beveiligde sleutels doorgaans niet optioneel. Door ze te combineren met uw ondertekeningsworkflow kunt u aan deze vereisten voldoen in plaats van ze te omzeilen.
Als u twijfelt over hoe u uw containerimages wilt ondertekenen en waar u het vertrouwen wilt vestigen, of als u hulp nodig hebt bij het implementeren van een ondertekeningsprogramma tot aan verplichte verificatie, neem dan contact met ons op . Wij kunnen u helpen bij het ontwerpen en bouwen van de PKI en de sleutelbeveiliging die daaronder vallen.
Conclusie
De vraag of je voor Notation of Cosign moet kiezen, gaat niet zozeer over welke tool meer functies heeft, maar over welk vertrouwensmodel het beste bij je organisatie past. De sleutelloze ondertekening van Cosign is snel te implementeren en uitstekend geschikt voor moderne, attestatie-rijke pipelines, met name voor teams die liever helemaal geen PKI beheren. De enterprise-PKI-aanpak van Notation is geschikt voor organisaties die al certificaten beheren, sleutels nodig hebben die ze zelf kunnen beheren en in hardware kunnen opslaan, en die moeten voldoen aan compliance-eisen die gebaseerd zijn op sleutelbeheer. Veel organisaties gebruiken uiteindelijk beide tools, voor verschillende fasen van dezelfde pipeline.
Wat je ook kiest, twee dingen blijven van belang. De handtekening moet gebaseerd zijn op een vertrouwensmodel waar je volledig achter kunt staan, en moet bij binnenkomst worden gehandhaafd, niet zomaar worden gezet en vervolgens vergeten. Een ondertekende afbeelding die niet geverifieerd wordt, is niet veiliger dan een ongetekende.
De regelgeving voor de toeleveringsketen zal niet versoepelen en de druk om aan te tonen waar uw software vandaan komt, zal alleen maar toenemen. De organisaties die dit jaar bewust hebben gekozen voor ondertekening en handhaving, en die vertrouwen hebben in een infrastructuur die ze zelf beheren, zullen de volgende compliance-eis beschouwen als een afgevinkt vakje in plaats van een brand die geblust moet worden.
