Cosign en External Secrets Operator: een Kubernetes-supplychain-baseline voor MSP's

Deze gids combineert twee opensourcecontroles die MSP's kunnen toepassen op een beheerde Kubernetes-omgeving: het ondertekenen en verifiëren van container-images met Sigstore Cosign, en het buiten Git houden van inloggegevens met External Secrets Operator. Samen dichten ze twee van de meest voorkomende gaten in een Kubernetes-supplychain — niet-geverifieerde images en hardgecodeerde secrets in manifests — zonder nieuw platform of leveranciersafhankelijkheid.

Ondertekenen bij de build, verifiëren bij de deploy

Cosign, onderdeel van het opensourceproject Sigstore, ondertekent en verifieert container-images zodat een Kubernetes-cluster kan bevestigen dat een image echt uit een goedgekeurde build-pipeline komt voordat die wordt uitgevoerd. Het patroon dat voor MSP's telt is eenvoudig: onderteken elke image bij de build, verifieer die handtekening bij admission of deploy, en wijs af wat niet klopt.

Ondertekenen kan met langlevende sleutels die een securityteam beheert, of via de keyless flow van Sigstore, waarbij Fulcio een kortlevend certificaat uitgeeft dat een tijdelijke sleutel koppelt aan een geverifieerde OpenID Connect-identiteit — een CI-systeem of een persoon — terwijl het transparantielogboek Rekor de gebeurtenis van een tijdstempel voorziet. Verificatie gebeurt vervolgens op het punt waar een image wordt uitgevoerd: een admission controller of deploy-gate controleert de handtekening tegen een goedgekeurde identiteit of sleutel, en blokkeert alles wat niet ondertekend of vertrouwd is voordat het een beheerd cluster bereikt.

Wat een handtekening niet vervangt

Een handtekening bewijst herkomst — dat een specifieke digest uit een specifieke pipeline of identiteit komt — maar zegt niets over de vraag of die digest bekende kwetsbaarheden bevat. Cosign is bedoeld naast een image-scanner zoals Trivy of Grype, niet in plaats daarvan: de scanner beoordeelt wat er in de image zit, de handtekening bewijst waar die vandaan komt. Wie "ondertekend" gelijkstelt aan "veilig" laat de helft van de controle liggen.

Secrets buiten Git houden met External Secrets Operator

External Secrets Operator is een Kubernetes-controller die externe secretbeheerders — waaronder AWS Secrets Manager, HashiCorp Vault en Azure Key Vault — koppelt aan native Kubernetes Secrets, zodat inloggegevens niet meer in een Git-repository of een Helm-chart hoeven te staan. Hij houdt een SecretStore- of ClusterSecretStore-resource in de gaten en synchroniseert waarden volgens een schema naar Kubernetes Secrets, zonder dat de operator zelf de platte tekst hoeft te loggen.

Door elke ExternalSecret te beperken tot de namespace en workload die hem echt nodig heeft, wordt de impact kleiner als een pod wordt gecompromitteerd. De operator blijft afhankelijk van de eigen toegangscontroles en het rotatiebeleid van de onderliggende secretbeheerder: hij haalt inloggegevens uit versiebeheer, maar vervangt niet de beveiliging van die secretbeheerder.

Waarom deze combinatie voor MSP's telt

Beheerde Kubernetes-omgevingen verzamelen vaak beide problemen tegelijk: secrets die uit gemak hardgecodeerd zijn, en images die zonder handtekeningcontrole uit een registry worden gehaald. Door External Secrets in het deploypad in te bouwen valt het excuus weg om inloggegevens in manifests te bewaren, terwijl een Cosign-admissionbeleid een MSP één controleerbare poort geeft om te bepalen of een image uit de eigen pipeline komt.

Geen van beide tools is op zichzelf een compleet securityprogramma. De verificatie van Cosign is maar zo sterk als het sleutelbeheer en het vertrouwen in de uitgevers erachter, en least privilege, netwerksegmentatie en incidentrespons blijven apart werk. Samen vormen de twee controles echter een herhaalbare baseline die per tenant kan worden toegepast, met een gedocumenteerd uitzonderingsproces voor wat nog niet voldoet.

MSP's die moeten aantonen dat deze controles een audit doorstaan, kunnen terecht bij de cybersecuritydiensten van Altovar, die penetratietests, kwetsbaarheidsbeoordelingen, incidentrespons en NIS2/DORA/GDPR-compliance dekken.

Wat te doen

• Onderteken elke image bij de build en verifieer die opnieuw bij admission of deploy; vertrouw nooit alleen op een handtekening uit de buildstap.
• Test eerst het faalpad: bevestig dat een niet-ondertekende of gemanipuleerde image echt wordt geweigerd voordat de poort in productie wordt vertrouwd.
• Combineer Cosign met een kwetsbaarhedenscanner zoals Trivy of Grype, want een geldige handtekening is niet hetzelfde als een schone scan.
• Haal elke inloggegeven uit manifests en Helm-charts naar een door External Secrets Operator beheerde SecretStore.
• Beperk elke ExternalSecret tot de namespace en workload die hem nodig heeft, en roteer sleutels of inloggegevens volgens een vast schema.
• Documenteer het uitzonderingsproces voor wat nog niet voldoet, en valideer beleidswijzigingen eerst in een niet-productiecluster voordat ze naar de hele omgeving worden uitgerold.

Bronnen: GitHub — sigstore/cosign, Sigstore-documentatie, External Secrets Operator op GitHub.