Nell'ecosistema cloud-native odierno, in continua evoluzione, Kubernetes è ormai lo standard di fatto per l'orchestrazione dei container. Avviamo pod in pochi istanti, scaricando le immagini dei container dai registry più disparati. Ma in questa corsa all'innovazione resta una domanda cruciale: sa davvero cosa gira nel suo cluster?
Se la risposta passa per la fiducia o per qualche supposizione sull'integrità delle immagini, il suo cluster sta operando alla cieca: un approccio rischioso in un'epoca segnata da attacchi alla supply chain sempre più sofisticati.
Con il crescente ricorso ai container per impacchettare e distribuire le applicazioni, garantire l'integrità e l'autenticità delle immagini in esecuzione nei propri cluster diventa imprescindibile. Verificare le immagini non è un "nice-to-have": è un pilastro non negoziabile di una solida postura di sicurezza Kubernetes.
Perché verificare le immagini dei container?
Le immagini dei container sono i mattoni delle sue applicazioni Kubernetes: racchiudono il codice, le sue dipendenze e l'ambiente di runtime. Questa praticità, però, può aprire la porta a vulnerabilità se le immagini non vengono controllate a dovere.
Ecco perché verificare le immagini non è più facoltativo:
- 🔓 Attacchi alla supply chain: gli attaccanti puntano sempre più spesso alla supply chain del software, iniettando codice malevolo in immagini all'apparenza legittime. Senza verifica, è solo questione di tempo prima di diventare una vittima a valle.
- 🐞 Vulnerabilità note: molte immagini si appoggiano a layer di base che includono pacchetti obsoleti o vulnerabili. Le immagini non verificate possono esporla a CVE (Common Vulnerabilities and Exposures) a sua insaputa.
- 🔧 Configurazioni errate: immagini eseguite come root, porte inutilizzate lasciate aperte o segreti scritti nel codice diventano vie d'accesso facili per gli attaccanti.
- 🎯 Errore umano: gli sviluppatori possono usare per sbaglio una versione più vecchia o una con nome simile ma non sicura. Senza controlli rigorosi, l'errore arriva dritto in produzione.
- 📋 Mancata conformità: standard come PCI DSS, SOC 2 e HIPAA impongono di dimostrare integrità e provenienza del software. Eseguire immagini non verificate significa rischiare audit falliti e sanzioni normative.
Senza sistemi di verifica solidi, il suo cluster Kubernetes rischia di trasformarsi in un ambiente fuori controllo, popolato da software non vagliato, con un'esposizione al rischio molto elevata.
Come Kyverno risolve e semplifica la verifica delle immagini
L'ecosistema Kubernetes mette a disposizione strumenti potenti per superare la logica della fiducia e imporre un'integrità verificabile. Tra le soluzioni di spicco c'è Kyverno, un policy engine pensato appositamente per Kubernetes.
Kyverno funziona da admission controller: intercetta le richieste API e applica le policy prima che i workloads vengano ammessi nel cluster. È quindi lo strumento ideale per imporre policy di verifica delle immagini al momento del deployment.
I principali vantaggi di Kyverno per la verifica delle immagini:
- ✅ Verifica delle firme delle immagini: impone la firma crittografica per assicurare che le immagini siano autentiche e integre.
- 📜 Controllo delle attestation: convalida i metadati firmati relativi all'immagine, come l'esito della scansione o la provenienza della build.
- 🔒 Restrizione dei registry: ammette solo immagini provenienti da fonti affidabili.
- 🏷️ Standard di tagging: garantisce che le immagini usino tag espliciti (evitando ad esempio
latest) e seguano convenzioni di versionamento coerenti.
Esempi di policy Kyverno per la verifica delle immagini
Vediamo qualche esempio concreto di policy. Prima di utilizzarle, si assicuri che Kyverno sia installato nel suo cluster.
Scenario 1: limitare le immagini ai registry approvati
Una policy semplice ma efficace consiste nel garantire che le immagini provengano solo dai registry affidabili della sua organizzazione.
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-registries
spec:
validationFailureAction: Enforce # Block deployments if validation fails
rules:
- name: validate-registries
match:
any:
- resources:
kinds:
- Pod
- Deployment
- StatefulSet
- Job
- CronJob
validate:
message: "Images must be pulled from approved registries (gcr.io or my.private.registry)."
pattern:
spec:
containers:
- image: "gcr.io/* | my.private.registry/*" # Allowed registry patterns
Se viene utilizzata un'immagine proveniente da un registry non approvato, il deployment viene bloccato con un messaggio di convalida chiaro.
Scenario 2: garantire che le immagini siano firmate con Cosign
Cosign, componente chiave del progetto Sigstore, è uno strumento ampiamente adottato per firmare e verificare crittograficamente gli artefatti software, archiviando firme e attestation all'interno di un registry OCI. Si assicuri che le chiavi pubbliche per la verifica delle immagini siano accessibili, tramite Kubernetes Secret o tramite URL.
Kyverno si integra direttamente con Cosign tramite la regola verifyImages, che impone policy in grado di convalidare le firme delle immagini di container e le attestation in-toto. In questo modo solo le immagini fidate e verificate vengono distribuite nel cluster Kubernetes.
Ecco una ClusterPolicy di Kyverno che impone a tutte le immagini distribuite nel namespace production di essere firmate con una chiave pubblica specifica:
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-signatures
spec:
validationFailureAction: Enforce
background: false
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: verify-image-signature
match:
any:
- resources:
kinds:
- Pod
namespaces:
- production
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # Adjust to your image pattern
attestors:
- count: 1
entries:
- keys:
publicKeys: | #The public key may either be defined in the policy directly or reference a standard Kubernetes Secret elsewhere in the cluster by specifying it in the format k8s://<namespace>/<secret_name>. The named Secret must specify a key cosign.pub containing the public key used for verification.
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyourPublicKeyContentHere...
-----END PUBLIC KEY-----
Un'immagine firmata può essere distribuita normalmente, mentre il tentativo di eseguire un'immagine non firmata produce un errore di policy come quello mostrato di seguito:
Scenario 3: verifica delle attestation delle scansioni di vulnerabilità
Un aspetto cardine per preservare l'integrità della supply chain del software è eseguire regolarmente scansioni delle vulnerabilità sulle immagini. Le scansioni effettuate al momento della build sono un buon punto di partenza, ma vanno ripetute man mano che emergono nuove vulnerabilità. Kyverno aiuta a far rispettare questa pratica controllando le attestation che dimostrano l'esito positivo di una scansione recente.
Ecco una ClusterPolicy di Kyverno tratta da Trivy, che applica un controllo di convalida sulle immagini dei Pod per assicurarsi che le relative scansioni delle vulnerabilità non risalgano a più di una settimana prima.
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-vulnerabilities
spec:
validationFailureAction: enforce
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: not-older-than-one-week
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # Adjust to your image pattern
attestations:
- predicateType: cosign.sigstore.dev/attestation/vuln/v1
conditions:
- all:
- key: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
operator: LessThanOrEquals
value: "168h"
Kyverno blocca la creazione del pod se l'immagine non è stata sottoposta di recente a una scansione delle vulnerabilità o se manca un'attestation di scansione firmata con Cosign.
Questi sono solo alcuni esempi. La flessibilità di Kyverno permette un controllo ben più granulare: dalla verifica di tag e label specifici al rifiuto di immagini con vulnerabilità ad alta gravità sulla base dei dati di attestation.
La verifica delle immagini non è una semplice best practice: è una necessità imprescindibile per operare in sicurezza in ambito cloud-native. Strumenti come Kyverno offrono un modo potente e flessibile per passare dalla fiducia cieca a una sicurezza verificabile. E quando si tratta di assicurarsi che i workloads siano non solo sicuri, ma anche correttamente dimensionati, affidabili ed efficienti dal punto di vista dei costi, piattaforme come PerfectScale completano gli strumenti di sicurezza analizzando in modo continuo i workloads Kubernetes alla ricerca di opportunità di ottimizzazione, senza mettere a rischio prestazioni o conformità.
Implementando la verifica delle firme delle immagini, i controlli sulle attestation e le restrizioni sui registry, può costruire una difesa solida contro un'ampia gamma di minacce rivolte alla supply chain del software.
Consulti la documentazione di Kyverno e Cosign per iniziare oggi stesso a proteggere i suoi workloads containerizzati. Se desidera saperne di più o è interessato ai nostri servizi, non esiti a contattarci. Può farlo da qui.