Cosign och External Secrets Operator: en Kubernetes-baslinje för MSP:er

Den här guiden kombinerar två öppen källkod-kontroller som MSP:er kan tillämpa i en förvaltad Kubernetes-flotta: att signera och verifiera containeravbildningar med Sigstore Cosign, och att hålla autentiseringsuppgifter borta från Git med External Secrets Operator. Tillsammans täpper de till två av de vanligaste luckorna i en Kubernetes-leveranskedja — overifierade avbildningar och hårdkodade hemligheter i manifest — utan en ny plattform eller leverantörsinlåsning.

Signera vid build, verifiera vid deploy

Cosign, en del av öppen källkod-projektet Sigstore, signerar och verifierar containeravbildningar så att ett Kubernetes-kluster kan bekräfta att en avbildning verkligen kommer från en godkänd build-pipeline innan den körs. Mönstret som spelar roll för MSP:er är enkelt: signera varje avbildning vid build, verifiera den signaturen vid admission eller deploy, och avvisa allt som inte håller.

Signering kan ske med långlivade nycklar som säkerhetsteamet kontrollerar, eller via Sigstores nyckellösa flöde, där Fulcio utfärdar ett kortlivat certifikat som binder en tillfällig nyckel till en verifierad OpenID Connect-identitet — ett CI-system eller en person — medan transparensloggen Rekor tidsstämplar händelsen. Verifieringen sker där en avbildning är på väg att köras: en admission controller eller en deploy-grind kontrollerar signaturen mot en godkänd identitet eller nyckel, och blockerar allt osignerat eller opålitligt innan det når ett förvaltat kluster.

Vad en signatur inte ersätter

En signatur bevisar ursprung — att en specifik digest kommer från en specifik pipeline eller identitet — men säger inget om huruvida den digesten innehåller kända sårbarheter. Cosign är tänkt att komplettera en avbildningsskanner som Trivy eller Grype, inte ersätta den: skannern bedömer vad som finns i avbildningen, signaturen bevisar var den kommer ifrån. Att likställa "signerad" med "säker" lämnar halva kontrollen oskyddad.

Håll hemligheter borta från Git med External Secrets Operator

External Secrets Operator är en Kubernetes-controller som kopplar externa hemlighetshanterare — bland andra AWS Secrets Manager, HashiCorp Vault och Azure Key Vault — till Kubernetes egna Secrets, så att autentiseringsuppgifter inte längre behöver ligga i ett Git-repo eller ett Helm-chart. Den bevakar en SecretStore- eller ClusterSecretStore-resurs och synkroniserar värden till Kubernetes Secrets enligt ett schema, utan att själva operatorn behöver logga klartexten.

Att begränsa varje ExternalSecret till den namespace och arbetslast som faktiskt behöver den minskar skadan om en pod komprometteras. Operatorn förblir beroende av den underliggande hemlighetshanterarens egna åtkomstkontroller och rotationspolicy: den flyttar autentiseringsuppgifter ut ur versionshanteringen, men ersätter inte den hanterarens säkerhet.

Varför kombinationen spelar roll för MSP:er

Förvaltade Kubernetes-flottor tenderar att samla på sig båda problemen samtidigt: hemligheter hårdkodade av bekvämlighet, och avbildningar hämtade från ett register utan signaturkontroll. Att koppla in External Secrets i deploy-flödet tar bort ursäkten att lagra autentiseringsuppgifter i manifest, medan en Cosign-admissionpolicy ger en MSP en enda granskningsbar grind för om en avbildning kommer från den egna pipelinen.

Inget av verktygen är ensamt ett fullständigt säkerhetsprogram. Cosigns verifiering är bara så stark som nyckelhanteringen och tilliten till utfärdarna bakom den, och minsta möjliga behörighet, nätverkssegmentering och incidenthantering förblir separata uppgifter. Tillsammans bildar de två kontrollerna dock en repeterbar baslinje som kan tillämpas per tenant, med en dokumenterad undantagsprocess för det som ännu inte uppfyller kraven.

MSP:er som behöver visa att de här kontrollerna håller vid en revision kan vända sig till Altovars cybersäkerhetstjänster, som täcker penetrationstester, sårbarhetsbedömning, incidenthantering och efterlevnad av NIS2/DORA/GDPR.

Vad du bör göra

• Signera varje avbildning vid build och verifiera den igen vid admission eller deploy; lita aldrig enbart på en signatur från build-steget.
• Testa felvägen först: bekräfta att en osignerad eller manipulerad avbildning verkligen avvisas innan grinden litas på i produktion.
• Kombinera Cosign med en sårbarhetsskanner som Trivy eller Grype, eftersom en giltig signatur inte är samma sak som en ren skanning.
• Flytta varje autentiseringsuppgift ut ur manifest och Helm-charts till en SecretStore som hanteras av External Secrets Operator.
• Begränsa varje ExternalSecret till den namespace och arbetslast som behöver den, och rotera nycklar eller autentiseringsuppgifter enligt ett fast schema.
• Dokumentera undantagsprocessen för det som ännu inte uppfyller kraven, och validera policyändringar i ett kluster utanför produktion innan de rullas ut i hela flottan.

Källor: GitHub — sigstore/cosign, Sigstore-dokumentation, External Secrets Operator på GitHub.