Bollettino sulla sicurezza

Seleziona una versione della documentazione:

Per valutare la security posture dei tuoi deployment Kubernetes di AlloyDB Omni e pianificare gli upgrade del control plane e del cluster di database, consulta le policy di sicurezza, l'architettura dell'operatore, controllo dell'accesso basato su ruoli (RBAC) e i contesti di sicurezza, nonché le pratiche di divulgazione di vulnerabilità ed esposizioni comuni (CVE) in questa pagina.

Per ricevere le note di rilascio e gli aggiornamenti della sicurezza più recenti di AlloyDB Omni nel tuo lettore di feed, iscriviti al feed delle note di rilascio di AlloyDB Omni.

Architettura dell'operatore e contesti di sicurezza

AlloyDB Omni su Kubernetes disaccoppia il control plane di Kubernetes dai pod del motore del database che elaborano le query dell'applicazione:

  • Componenti del control plane e dell'operatore: ogni release dell'operatore AlloyDB Omni comprende 10 immagini container create su Red Hat Universal Base Image 9 (UBI 9):
    • operator/fleet-operator: controller Kubernetes a livello di parco risorse che riconcilia le risorse personalizzate DBCluster e del parco risorse
    • operator/local-operator: controller Kubernetes a livello di istanza che gestisce i cicli di vita dei pod del database locale e comunica solo con il server API Kubernetes interno al cluster attendibile
    • alloydbomni-operator-catalog e alloydbomni-operator-olm-bundle: indice del catalogo di Red Hat OpenShift Operator Lifecycle Manager (OLM) e immagini dei metadati del bundle dichiarativo
    • operator/dbinit e operator/backupinit: container di inizializzazione temporanei per i workflow di bootstrap, backup e ripristino del database
    • operator/alloydbomni-monitor (sostituisce monitoring-agent), operator/g-pgbouncer, operator/logrotate e operator/node-manager: container sidecar e Node Manager complementari per il controllo di integrità, il connection pooling, la rotazione dei log e la gestione dello spazio di archiviazione
  • RBAC e contesti di sicurezza: l'operatore AlloyDB Omni utilizza autorizzazioni Kubernetes Role e ClusterRole con ambito per riconciliare le risorse personalizzate all'interno degli spazi dei nomi di destinazione ed esegue i workload del control plane e del sidecar con contesti di sicurezza dei container limitati.
  • Pod del motore del database: le istanze di database gestite dall'operatore eseguono le immagini container del kernel del database AlloyDB Omni autonomo. Per verificare quali versioni kernel del database sono supportate per la tua versione dell'operatore, consulta Scegli le versioni compatibili dell'operatore Kubernetes e del cluster di database.

Filtro per ambito e gravità

Per concentrare i workflow di correzione su avvisi di sicurezza utili e ridurre il rumore dello scanner, i riepiloghi delle vulnerabilità di AlloyDB Omni e i log CVE dettagliati seguono queste policy di reporting:

  • Filtro rigoroso per gravità critica e alta: le tabelle di riepilogo delle vulnerabilità e i log CVE dettagliati segnalano esclusivamente le CVE con gravità critica e alta in base alle valutazioni di gravità del National Vulnerability Database (NVD) e del vendor upstream. I suggerimenti con gravità bassa e media sono esclusi dai conteggi di riepilogo e dai log dettagliati.
  • Reporting separato del control plane e del kernel del database: i bollettini del control plane in AlloyDB Omni su Kubernetes segnalano le vulnerabilità specifiche delle 10 immagini container dell'operatore e del sidecar di AlloyDB Omni.
  • Isolamento specifico per versione: i log CVE dettagliati sono organizzati in sottopagine dedicate per versione di release utilizzando uno schema standardizzato a 4 colonne (CVE ID, Severity, Impacted images e Mitigated in). All'interno di ogni log di release, le vulnerabilità corrette in una release successiva mostrano la versione di release di mitigazione nella colonna Mitigated in.

Criterio di valutazione e aggiornamento delle vulnerabilità

Google analizza regolarmente tutte le immagini container AlloyDB Omni pubblicate rispetto ai database delle vulnerabilità NVD, Red Hat Security Data, Debian Security Tracker e Go. Google aggiorna i bollettini sulla sicurezza di AlloyDB Omni quando vengono pubblicate nuove release:

  • CVE corretti: le vulnerabilità presenti in un'immagine container del control plane dell'operatore AlloyDB Omni precedente vengono mitigate in una release successiva dell'operatore. Google applica le patch di sicurezza all'ultima release supportata dell'operatore AlloyDB Omni e all'ultima versione secondaria delle versioni principali di PostgreSQL supportate 18, 17, 16 e 15.
  • Immagini container sostituite: quando una nuova release di AlloyDB Omni operator mitiga le CVE di una release precedente, Google contrassegna i digest delle immagini container sostituite come deprecati. Esegui sempre il deployment delle immagini dell'operatore e dell'agente del control plane che corrispondono all'ultima release supportata.

Conformità a FIPS 140-3 e applicazione di patch CVE

Per mantenere la conformità con i Federal Information Processing Standard (FIPS) 140-3 e applicare continuamente patch alle vulnerabilità di sicurezza nelle release minori e nelle patch, AlloyDB Omni disaccoppia i moduli crittografici interni convalidati FIPS dalle librerie crittografiche e di protocollo esterne:

  • Convalida FIPS per i moduli di crittografia: il Cryptographic Module Validation Program (CMVP) del National Institute of Standards and Technology (NIST) certifica un modulo o un provider di crittografia interno bloccato ed emette un numero di certificato. La modifica di qualsiasi istruzione all'interno di questo confine convalidato altera il checksum di integrità HMAC (Hash-based Message Authentication Code) incorporato e invalida il certificato.
  • Conformità FIPS per i deployment: un deployment AlloyDB Omni opera in modalità conforme a FIPS 140-3 quando viene eseguito su un sistema operativo host abilitato per FIPS, come Red Hat Enterprise Linux (RHEL) 9 con il file /proc/sys/crypto/fips_enabled impostato su 1. In questa modalità, il deployment instrada tutte le operazioni di crittografia relative alla sicurezza tramite un modulo convalidato FIPS con test di risposta nota (KAT) all'accensione e controlli di integrità HMAC abilitati. Inoltre, applica le versioni approvate di Transport Layer Security (TLS) 1.2 o successive, le suite di crittografia approvate e il metodo di autenticazione con password scram-sha-256. Le immagini container dell'operatore AlloyDB Omni e le immagini container del database Red Hat UBI 9 (-ubi9) sono compatibili con FIPS e la tua organizzazione è responsabile dell'attivazione e della verifica della modalità FIPS sul sistema operativo host sottostante. Per saperne di più, consulta Sicurezza e conformità FIPS.
  • Applicazione di patch CVE al di fuori del confine FIPS: le librerie di analisi dei protocolli e di networking, come le macchine di stato TLS, l'analisi dei certificati X.509 e ASN.1, HTTP/2 e l'I/O di rete, risiedono nel livello esterno al di fuori del confine del modulo FIPS bloccato. Poiché questi componenti si trovano al di fuori del confine convalidato, Google applica patch alle CVE del livello esterno nelle release secondarie e nelle patch senza modificare il modulo crittografico interno o invalidare la certificazione NIST CMVP. Solo una vulnerabilità all'interno dell'implementazione della primitiva crittografica di basso livello richiede un aggiornamento del modulo FIPS interno.
La tabella seguente descrive gli stack crittografici nei control plane e nelle immagini container sidecar di AlloyDB Omni operator, inclusi il confine FIPS interno bloccato e il livello crittografico e di protocollo esterno con patch applicate tra le release:

Stack di crittografia Immagini container del control plane Programmi binari Modulo o provider interno convalidato FIPS Livello di protocollo e crittografico esterno
FIPS integrato in Go con l'impostazione di build GOFIPS140=v1.0.0 operator/fleet-operator
operator/local-operator
operator/logrotate
operator/node-manager
operator/dbinit
operator/backupinit 		/operator
/local
/logrotate
/nodemgr
dbinit
dbdaemon
credfetcher
backupinit
backupdaemon 		Modulo crittografico Go v1.0.0, certificato NIST CMVP n. 5247 Pacchetti della libreria standard Go crypto/tls, crypto/x509 e net/http, pacchetti Go esterni come golang.org/x/crypto, nonché il runtime e il compilatore Go
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer Provider FIPS OpenSSL RHEL 9 /lib64/libssl.so.3 e /lib64/libcrypto.so.3 nel pacchetto RPM openssl-libs e il programma binario C pgbouncer
BoringSSL e BoringCrypto operator/alloydbomni-monitor /monitoring_agent File binario Go creato con boringcrypto Google BoringCrypto Module (BCM) Pacchetti Go crypto/tls, crypto/x509 e net/http per monitoring_agent

Passaggi successivi