In questo articolo6
Ascolta
Voce del browser e privacy
Parte solo quando premi Ascolta. Alcune voci possono usare un servizio online. La nuova velocità può applicarsi dal passaggio successivo. Il testo non viene tradotto.
Il problema: operatori Kubernetes con permessi eccessivi
Gli operatori Kubernetes sono componenti software che automatizzano la gestione di applicazioni complesse all'interno di un cluster, come database o policy di firewall. Per funzionare, questi operatori richiedono account di servizio con permessi specifici (RBAC, Role-Based Access Control). Il problema, secondo i ricercatori di Unit 42 di Palo Alto Networks, è che molti di questi operatori vengono distribuiti con privilegi molto più ampi di quelli necessari.
Se un attaccante compromette un operatore, la portata del danno è definita interamente dai suoi permessi RBAC. Un operatore con accesso eccessivo funziona come una backdoor silenziosa, indipendentemente dal fatto che il compromesso derivi da una vulnerabilità nella catena di fornitura, da una dipendenza compromessa o dal dirottamento del nodo sottostante.
OperTraitor: uno strumento per misurare il rischio
Per quantificare il problema, Unit 42 ha sviluppato OperTraitor, un motore di analisi open source basato su modelli linguistici di grandi dimensioni (LLM). Lo strumento raccoglie le configurazioni RBAC direttamente dagli operatori installati localmente e dal catalogo OperatorHub, quindi calcola la differenza tra la funzionalità documentata di un operatore e i privilegi effettivamente concessi.
OperTraitor assegna un punteggio di rischio da 1 a 10, aiutando i difensori a visualizzare l'impatto potenziale degli operatori di terze parti. I team di sicurezza possono quindi ridurre i permessi degli account di servizio prima che vengano sfruttati.
Il caso IBM Turbonomic: CVE-2026-6389
Durante l'analisi, OperTraitor ha identificato una vulnerabilità ad alta gravità (CVE-2026-6389, CVSS 8.8) nell'operatore Prometurbo di IBM Turbonomic. La versione su OperatorHub era gravemente obsoleta (v8.6.0 del 2022), ma anche la versione più recente disponibile su GitHub (v8.17.6) presentava il problema.
L'account di servizio dell'operatore era legato a un ClusterRole con una regola esplicita che concedeva i verbi get, list e watch sulla risorsa secrets nell'API core. Ciò significa che l'operatore poteva leggere tutti i segreti dell'intero cluster, non solo quelli del proprio namespace. Se compromesso, un attaccante avrebbe potuto estrarre token di account di servizio amministrativi, credenziali di database, chiavi API e certificati TLS da namespace non correlati, trasformando una violazione localizzata in un compromesso totale dell'ambiente.
IBM ha risposto prontamente alla segnalazione, ha corretto il problema in una release successiva e ha pubblicato un bollettino di sicurezza con la CVE-2026-6389. La segnalazione è avvenuta il 5 novembre 2025, la risoluzione è stata confermata il 3 febbraio 2026 e il bollettino è stato pubblicato il 24 aprile 2026.
Il caso Datadog: il compromesso tra sicurezza e usabilità
OperTraitor ha anche segnalato l'operatore Datadog per una configurazione eccessivamente privilegiata, con accesso cluster-wide ai segreti e azioni su risorse RBAC come ClusterRoles e ClusterRoleBindings.
Datadog ha spiegato che i nomi dei segreti a cui l'operatore deve accedere si basano su valori definiti dall'utente, rendendoli impossibili da prevedere prima della distribuzione. L'azienda ha scelto di aggiungere una spiegazione dettagliata delle proprie impostazioni RBAC e delle mitigazioni applicate, consentendo ai team di sicurezza di prendere decisioni informate sull'accettazione del rischio.
Il problema più ampio: operatori abbandonati su OperatorHub
La ricerca ha rivelato una debolezza significativa nella catena di fornitura: OperatorHub è pieno di componenti abbandonati e eccessivamente permissivi. Molti vendor pubblicano versioni nuove e sicure dei loro operatori esclusivamente tramite Helm chart, repository GitHub o ArtifactHub, ma le versioni più vecchie e vulnerabili rimangono facilmente accessibili tramite Operator Lifecycle Manager (OLM), lo standard di default negli ambienti OpenShift.
Gli utenti distribuiscono così operatori obsoleti in pochi clic, spesso senza rendersene conto. I vendor, in molti casi, non danno priorità alla manutenzione o alla deprecazione dei componenti legacy su OperatorHub. Inoltre, molti proprietari degli operatori contattati non hanno risposto alle segnalazioni di divulgazione responsabile, un segnale che i componenti non sono più mantenuti attivamente.
Raccomandazioni per i team di sicurezza
Unit 42 raccomanda di non fidarsi implicitamente delle versioni disponibili su OLM o OperatorHub, verificando sempre la documentazione ufficiale del vendor e distribuendo gli operatori tramite Helm chart mantenuti, ArtifactHub o repository GitHub ufficiali.
Altre misure suggerite includono: limitare gli operatori ai namespace specifici che gestiscono, evitando operatori cluster-scoped quando possibile; validare i manifest YAML forniti dai vendor e controllare regolarmente la postura RBAC; monitorare i log di audit di Kubernetes per rilevare attività anomale degli account di servizio; e stabilire policy di rete rigorose per gli operatori che usano LLM o framework agentici, limitando l'accesso a internet pubblico e gli endpoint interni non autorizzati.
