Proteggere la supply chain e i secret

Un'immagine container viene creata a partire da immagini di base, pacchetti del sistema operativo e dipendenze dell'applicazione, quindi viene trasferita attraverso un registry nel cluster. Ogni passaggio può essere sfruttato per compromettere il sistema. Gli attacchi alla catena di fornitura inseriscono codice dannoso prima ancora che raggiunga la produzione.

• Immagini di base o dipendenze compromesse.
• Immagini alterate nel registry.
• Passaggi dannosi nella pipeline CI/CD.

Le immagini includono spesso pacchetti con vulnerabilità note. La scansione consente di rilevarle prima del deployment.

• Le immagini di base obsolete accumulano CVE.
• Le immagini sovraccariche ampliano la superficie d'attacco.
• I secret incorporati nei layer delle immagini espongono le credenziali.

Riduca la superficie d'attacco partendo da una base minima e verificata.

• Utilizzi immagini di base distroless o minimali (senza shell né package manager).
• Blocchi le immagini di base tramite digest, non tramite tag mobili.
• Preferisca immagini di base ufficiali o verificate internamente.

Un'immagine più piccola contiene meno CVE e offre all'attaccante meno strumenti da sfruttare dopo la compromissione.

La firma dimostra che un'immagine proviene dalla propria pipeline e non è stata alterata. La provenienza (SLSA) registra il processo con cui è stata creata.

• Cosign firma e verifica le immagini.
• Generi un SBOM per tenere traccia di ogni componente.
• Alleghi attestazioni sulla provenienza della build.

Imponi che vengano eseguite solo immagini firmate e sottoposte a scansione. Un controller di ammissione rifiuta le immagini non firmate o vulnerabili al momento del deployment.

Il sistema CI/CD è un obiettivo di grande valore: contiene credenziali e può effettuare il push in produzione.

• Limiti le credenziali della pipeline applicando il privilegio minimo e durate brevi.
• Blocchi e verifichi le CI action e i plugin di terze parti.
• Isoli i build runner; non li riutilizzi tra livelli di attendibilità diversi.
• Protegga il registry con autenticazione e immutabilità.

Per impostazione predefinita, i Kubernetes Secrets sono codificati in base64, non crittografati. Chiunque possa leggerli, o leggere etcd, visualizza il testo in chiaro.

Protegga i contenuti di etcd, in modo che il furto di un backup o l'accesso a etcd non espongano tutto.

• Abiliti la crittografia a riposo tramite una EncryptionConfiguration.
• Utilizzi un provider cloud KMS per la crittografia envelope.
• Limiti e sottoponga ad audit l'accesso diretto a etcd.

Il modello più sicuro mantiene completamente i secret fuori dall'archivio del cluster.

• HashiCorp Vault o i gestori di secret cloud conservano la fonte autorevole.
• External Secrets Operator o il driver CSI li inietta a runtime.
• Utilizzi la workload identity, così i pod recuperano i secret tramite token cloud a breve durata, anziché tramite chiavi statiche.

Le pratiche operative riducono l'esposizione dei secret.

• Non inserisca mai i secret nelle immagini né li sottoponga a commit in Git.
• Esegua la scansione dei repository e delle immagini per individuare credenziali esposte.
• Ruoti i secret regolarmente e in caso di sospetta esposizione.
• Limiti RBAC get/list secrets allo stretto necessario.

Durante la valutazione, verifichi che le immagini non firmate o vulnerabili vengano effettivamente bloccate, che i Secrets siano crittografati a riposo e che nelle immagini o in Git non siano presenti credenziali in chiaro. Dimostri i risultati senza esfiltrare secret reali oltre quanto necessario per la prova.

Segnali ogni lacuna indicando il controllo concreto (policy di firma, crittografia KMS, gestore esterno) che la risolve.

Verifichi le proprie conoscenze sulla catena di fornitura e sui secret.

Ha rafforzato la catena di fornitura delle immagini e la gestione dei secret.

• Sottoponga le immagini a scansione, utilizzi immagini di base minime e bloccate e firmi con cosign.
• Applichi immagini firmate e sottoposte a scansione e registry affidabili al momento dell'ammissione.
• I Kubernetes Secrets sono solo codificati in base64: abiliti la crittografia KMS a riposo.
• Preferisca gestori esterni dei secret e la workload identity; applichi una corretta igiene dei secret.

Questo completa il corso Kubernetes Security e questo insieme di lezioni.