Cosign e External Secrets Operator: una baseline di supply chain Kubernetes per gli MSP

Questa guida unisce due controlli open source che gli MSP possono applicare su una flotta Kubernetes gestita: firmare e verificare le immagini container con Sigstore Cosign, e tenere le credenziali fuori da Git con External Secrets Operator. Usati insieme, chiudono due delle lacune più comuni nella supply chain Kubernetes — immagini non verificate e segreti scritti direttamente nei manifest — senza bisogno di una nuova piattaforma o di un vendor lock-in.

Firma in build, verifica al deploy

Cosign, parte del progetto open source Sigstore, firma e verifica le immagini container in modo che un cluster Kubernetes possa confermare che un'immagine proviene davvero da una pipeline di build approvata prima che venga eseguita. Lo schema che conta per gli MSP è semplice: firma ogni immagine in fase di build, poi verifica quella firma in fase di ammissione o di deploy, e rifiuta tutto ciò che non risulta valido.

Per firmare puoi usare chiavi di lunga durata controllate dal tuo team di sicurezza, oppure il flusso keyless di Sigstore, in cui Fulcio rilascia un certificato di breve durata che lega una chiave effimera a un'identità OpenID Connect verificata — un sistema CI o una persona — mentre il registro di trasparenza Rekor mette una marca temporale sull'evento. La verifica avviene poi nel punto in cui un'immagine sta per essere eseguita: un admission controller o un gate di deploy controlla la firma rispetto a un'identità o a una chiave approvata, e blocca tutto ciò che non è firmato o attendibile prima che raggiunga un cluster gestito.

Cosa non sostituisce la firma

Una firma dimostra la provenienza — che un determinato digest proviene da una pipeline o da un'identità specifica — ma non dice nulla sul fatto che quel digest contenga vulnerabilità note. Cosign è pensato per affiancare uno scanner di immagini come Trivy o Grype, non per sostituirlo: lo scanner valuta cosa c'è dentro l'immagine, la firma dimostra da dove proviene. Considerare "firmato" sinonimo di "sicuro" lascia scoperta metà del controllo.

Tenere i segreti fuori da Git con External Secrets Operator

External Secrets Operator è un controller Kubernetes che collega gestori di segreti esterni — tra cui AWS Secrets Manager, HashiCorp Vault e Azure Key Vault — ai Secret Kubernetes nativi, così le credenziali non devono più stare in un repository Git o in un chart Helm. Osserva una risorsa SecretStore o ClusterSecretStore e sincronizza i valori nei Secret Kubernetes secondo una pianificazione, senza che l'operator stesso debba registrare il testo in chiaro.

Separa ogni ExternalSecret per limitarlo al namespace e al workload che ne ha davvero bisogno: così riduci il raggio d'impatto se un pod viene compromesso. L'operator dipende comunque dai controlli di accesso e dalla policy di rotazione del gestore di segreti sottostante: sposta le credenziali fuori dal version control, ma non sostituisce le difese del gestore di segreti.

Perché questa combinazione conta per gli MSP

Le flotte Kubernetes gestite tendono ad accumulare entrambi i problemi insieme: segreti scritti direttamente per comodità, e immagini scaricate da un registry senza un controllo della firma. Integrare External Secrets nel percorso di deploy toglie la scusa di archiviare credenziali nei manifest, mentre una policy di ammissione Cosign dà a un MSP un unico gate verificabile per stabilire se un'immagine proviene dalla propria pipeline.

Nessuno dei due strumenti è di per sé un programma di sicurezza completo. La verifica di Cosign vale quanto la gestione delle chiavi e la fiducia negli emittenti che ci sono dietro, e privilegi minimi, segmentazione di rete e risposta agli incidenti restano attività separate. Trattati insieme, però, i due controlli diventano una baseline ripetibile applicabile per tenant, con un processo di eccezione documentato per tutto ciò che non è ancora conforme.

Se devi dimostrare che questi controlli reggono in un audit, puoi rivolgerti ai servizi di cybersecurity di Altovar, che coprono penetration test, vulnerability assessment, incident response e conformità NIS2/DORA/GDPR.

Cosa fare

• Firma ogni immagine in fase di build e verificala di nuovo in ammissione o al deploy; non fidarti mai di una firma dal solo passaggio di build.
• Testa per primo il percorso di errore: verifica che un'immagine non firmata o manomessa venga davvero respinta prima di fidarti del gate in produzione.
• Affianca a Cosign uno scanner di vulnerabilità come Trivy o Grype, perché una firma valida non equivale a una scansione pulita.
• Sposta ogni credenziale fuori dai manifest e dai chart Helm in un SecretStore gestito da External Secrets Operator.
• Limita ogni ExternalSecret al namespace e al workload che ne ha bisogno, e ruota chiavi e credenziali con una pianificazione definita.
• Documenta il processo di eccezione per ciò che non è ancora conforme, e convalida le modifiche alle policy in un cluster non di produzione prima di estenderle a tutta la flotta.

Fonti: GitHub — sigstore/cosign, documentazione Sigstore, External Secrets Operator su GitHub.