Plataforma de datos apilables 26.7: seguridad, SBOM y registros flexibles

Esta actualización se centra en la garantía de calidad para su plataforma modular de código abierto basada en Kubernetes. Los cambios tienen como objetivo reducir la deuda técnica, estabilizar los canales de integración continua y limpiar las pruebas inestables. Las mejoras incluyen la selección dinámica de registros, la seguridad mejorada de la cadena de suministro y la introducción de un directorio central llamado Stackable Hub.

Además, se han abordado 133 vulnerabilidades (10 críticas y 62 CVEs de alta gravedad). Uno de los cambios más impactantes involucra cómo los operadores recuperan las imágenes de sus productos. La tecnología estaba codificada en la configuración de la plataforma. Los ajustes para entornos con brecha de aire o registros internos de espejo requerían ediciones manuales a través de valores de Helm o configuraciones de contenedores a nivel de nodo, una solución alternativa que se volvió cada vez más engorroso a medida que la plataforma se escalaba.

Cuando se instala un operador a través del gráfico de Helm o el manifiesto de OLM, la plataforma establece automáticamente este valor en función del registro del que se origina el operador. io por defecto. io, eliminando la necesidad de espejo manual. Para instalaciones fuera de Helm u OLM, este cambio representa una actualización de ruptura. Los usuarios que implementan operadores manualmente a través de archivos YAML personalizados, Kustomize o ArgoCD deben establecer explícitamente --image-repository dentro del bloque de argumentos del contenedor del operador. tech/sdp o apuntar a un registro de espejo interno. campo de repositorio, eliminando el nombre del operador. tech/sdp. Si no se realizan estos ajustes, se producen errores de ImagePull, lo que hace que los pods fallen durante el inicio.

Se recomienda encarecidamente una implementación de prueba en un entorno de puesta en escena antes de la actualización a la producción. Este cambio mueve la portabilidad del registro de soluciones específicas del producto a la lógica de toda la plataforma. Para escenarios con brecha de aire, la variable IMAGE_REPOSITORY se puede dirigir a un registro interno, siempre que las imágenes del producto se hayan reflejado de manera consistente allí, una ventaja para las arquitecturas soberanas e interoperables. El segundo tema principal de los centros de actualización se centra en la procedencia de SLSA y SPDX SBOM, con el objetivo de mejorar la trazabilidad a lo largo de la cadena de suministro de software.

Estas adiciones proporcionan una mayor transparencia y control sobre las dependencias, alineándose con los estándares de la industria para operaciones seguras y conformes.