Boletín de seguridad

Selecciona una versión de la documentación:

Para evaluar la postura de seguridad de tus implementaciones de AlloyDB Omni en Kubernetes y planificar las actualizaciones del plano de control y del clúster de la base de datos, revisa las políticas de seguridad, la arquitectura del operador, el control de acceso basado en roles (RBAC) y los contextos de seguridad, y las prácticas de divulgación de vulnerabilidades y exposiciones comunes (CVE) en esta página.

Para recibir las notas de la versión y las actualizaciones de seguridad más recientes de AlloyDB Omni en tu lector de feeds, suscríbete al feed de notas de la versión de AlloyDB Omni.

Arquitectura del operador y contextos de seguridad

AlloyDB Omni en Kubernetes separa el plano de control de Kubernetes de los Pods del motor de base de datos que procesan las consultas de la aplicación:

  • Componentes del plano de control y del operador: Cada versión del operador de AlloyDB Omni incluye 10 imágenes de contenedor compiladas en Red Hat Universal Base Image 9 (UBI 9):
    • operator/fleet-operator: Controlador de Kubernetes a nivel de la flota que concilia los recursos personalizados de DBCluster y de la flota
    • operator/local-operator: Es un controlador de Kubernetes a nivel de la instancia que administra los ciclos de vida de los Pods de la base de datos local y se comunica solo con el servidor de la API de Kubernetes interno del clúster de confianza.
    • alloydbomni-operator-catalog y alloydbomni-operator-olm-bundle: Índice del catálogo de Operator Lifecycle Manager (OLM) de Red Hat OpenShift y las imágenes de metadatos del paquete declarativo
    • operator/dbinit y operator/backupinit: Contenedores de inicialización efímeros para los flujos de trabajo de arranque, copia de seguridad y restablecimiento de la base de datos
    • operator/alloydbomni-monitor (reemplaza a monitoring-agent), operator/g-pgbouncer, operator/logrotate y operator/node-manager: Contenedores de Node Manager y sidecar complementarios para el sondeo de estado, la agrupación de conexiones, la rotación del registro y la administración del almacenamiento
  • RBAC y contextos de seguridad: El operador de AlloyDB Omni usa permisos de Kubernetes con alcance de Role y ClusterRole para conciliar recursos personalizados dentro de los espacios de nombres de destino y ejecuta cargas de trabajo del plano de control y de sidecar con contextos de seguridad de contenedores restringidos.
  • Pods del motor de base de datos: Las instancias de base de datos administradas por el operador ejecutan las imágenes de contenedor del kernel de la base de datos de AlloyDB Omni independiente. Para verificar qué versiones de kernel de base de datos son compatibles con tu versión de operador, consulta Elige versiones compatibles de operadores de Kubernetes y clústeres de bases de datos.

Filtrado por alcance y gravedad

Para enfocar los flujos de trabajo de solución en avisos de seguridad prácticos y reducir el ruido del análisis, los resúmenes de vulnerabilidades de AlloyDB Omni y los registros detallados de CVE siguen estas políticas de informes:

  • Filtrado estricto de gravedad alta y crítica: Las tablas de resumen de vulnerabilidades y los registros detallados de CVE informan exclusivamente las CVE de gravedad alta y crítica según las calificaciones de gravedad de la Base de datos nacional de vulnerabilidades (NVD) y del proveedor upstream. Los avisos de gravedad baja y media se excluyen de los recuentos de resumen y los registros detallados.
  • Informes desacoplados del plano de control y del kernel de la base de datos: Los boletines del plano de control en AlloyDB Omni en Kubernetes informan vulnerabilidades específicas de las 10 imágenes de contenedor de sidecar y del operador de AlloyDB Omni.
  • Aislamiento específico de la versión: Los registros detallados de CVE se organizan en subpáginas dedicadas por versión de actualización con un esquema estandarizado de 4 columnas (CVE ID, Severity, Impacted images y Mitigated in). Dentro de cada registro de actualización, las vulnerabilidades corregidas en una actualización posterior muestran la versión de actualización de mitigación en la columna Mitigated in.

Evaluación de vulnerabilidades y política de actualización

Google analiza con regularidad todas las imágenes de contenedor de AlloyDB Omni publicadas en las bases de datos de vulnerabilidades de NVD, Red Hat Security Data, Debian Security Tracker y Go. Google actualiza los boletines de seguridad de AlloyDB Omni cuando se publican versiones nuevas:

  • CVE corregidas: Las vulnerabilidades que estaban presentes en una imagen de contenedor del plano de control del operador de AlloyDB Omni anterior se mitigan en una versión posterior del operador. Google aplica parches de seguridad a la versión más reciente del operador de AlloyDB Omni compatible y a la versión secundaria más reciente de las versiones principales de PostgreSQL 18, 17, 16 y 15 compatibles.
  • Imágenes de contenedor reemplazadas: Cuando una nueva versión del operador de AlloyDB Omni mitiga las CVE de una versión anterior, Google marca los resúmenes de imágenes de contenedor reemplazados como obsoletos. Implementa siempre imágenes de agentes del operador y del plano de control que correspondan a la versión compatible más reciente.

Cumplimiento de FIPS 140-3 y aplicación de parches de CVE

Para mantener el cumplimiento de los Estándares federales de procesamiento de la información (FIPS) 140-3 mientras se corrigen de forma continua las vulnerabilidades de seguridad en las versiones secundarias y de parches, AlloyDB Omni separa sus módulos criptográficos internos validados por FIPS de sus bibliotecas criptográficas y de protocolos externas:

  • Validación de FIPS para módulos criptográficos: El Programa de validación de módulos criptográficos (CMVP) del Instituto Nacional de Estándares y Tecnología (NIST) certifica un módulo o proveedor criptográfico interno inmovilizado y emite un número de certificado. Si se modifica cualquier instrucción dentro de ese límite validado, se altera la suma de comprobación de integridad del código de autenticación de mensajes basado en hash (HMAC) incorporado y se invalida el certificado.
  • Cumplimiento de FIPS para implementaciones: Una implementación de AlloyDB Omni funciona en un modo que cumple con la norma FIPS 140-3 cuando se ejecuta en un SO host habilitado para FIPS, como Red Hat Enterprise Linux (RHEL) 9 con el archivo /proc/sys/crypto/fips_enabled configurado como 1. En este modo, la implementación enruta todas las operaciones criptográficas relevantes para la seguridad a través de un módulo validado por FIPS con pruebas de respuesta conocida (KAT) de encendido y verificaciones de integridad de HMAC habilitadas. También aplica las versiones aprobadas de seguridad de la capa de transporte (TLS) de TLS 1.2 o posterior, los conjuntos de algoritmos de cifrado aprobados y el método de autenticación de contraseña de scram-sha-256. Las imágenes de contenedor del operador de AlloyDB Omni y las imágenes de contenedor de la base de datos de Red Hat UBI 9 (-ubi9) están listas para FIPS, y tu organización es responsable de habilitar y verificar el modo FIPS en el SO host subyacente. Para obtener más información, consulta Seguridad y cumplimiento de FIPS.
  • Aplicación de parches de CVE fuera del límite de FIPS: Las bibliotecas de análisis de protocolos y de redes, como las máquinas de estado de TLS, el análisis de certificados X.509 y ASN.1, HTTP/2 y las E/S de red, residen en la capa externa fuera del límite del módulo de FIPS inmovilizado. Debido a que estos componentes se encuentran fuera del límite validado, Google aplica parches para las CVE de la capa externa en las versiones secundarias y de parches sin modificar el módulo criptográfico interno ni invalidar su certificación CMVP del NIST. Solo una vulnerabilidad dentro de la implementación de la primitiva criptográfica de bajo nivel requiere una actualización del módulo de FIPS interno.
En la siguiente tabla, se describen las pilas criptográficas en las imágenes del contenedor sidecar y el plano de control del operador de AlloyDB Omni, incluidos el límite interno de FIPS inmovilizado y la capa criptográfica y de protocolo externa que se parcha en las versiones:

Pila criptográfica Imágenes de contenedor del plano de control Objetos binarios Módulo o proveedor interno validado por FIPS Capa criptográfica y de protocolo externa
FIPS integrado de Go con el parámetro de configuración de compilación 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 		Módulo criptográfico de Go v1.0.0, certificado del CMVP del NIST núm. 5247 Paquetes de la biblioteca estándar de Go crypto/tls, crypto/x509 y net/http, paquetes externos de Go, como golang.org/x/crypto, y el entorno de ejecución y el compilador de Go
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer Proveedor de FIPS de OpenSSL de RHEL 9 /lib64/libssl.so.3 y /lib64/libcrypto.so.3 en el paquete RPM openssl-libs, y el objeto binario de C pgbouncer
BoringSSL y BoringCrypto operator/alloydbomni-monitor Objeto binario de Go /monitoring_agent compilado con boringcrypto Módulo BoringCrypto de Google (BCM) Paquetes de Go crypto/tls, crypto/x509 y net/http para monitoring_agent

¿Qué sigue?