La innovación aún necesita experiencia en seguridad de TI
Cometario de Ashesh Badani, VP/GM, Cloud Platforms BU de Red Hat, acerca del fallo de escalada de privilegios de Kubernetes.
La seguridad del TI es importante en todos los niveles del stack tecnológico de la empresa, desde la base de la infraestructura hasta las aplicaciones de misión crítica y servicios expuestos a los usuarios finales. Esta necesidad se da del mismo modo independientemente de si la tecnología es un producto básico o se encuentra a la vanguardia. En resumen, la seguridad TI siempre es importante.
Para el software de código abierto que está impulsando frecuentemente innovaciones utilizadas por empresas actuales, como Linux, la nube híbrida, los contendores o las tecnologías de Kubernetes, este equilibrio entre innovación, seguridad y estabilidad da buena muestra del valor que puede ofrecer una suscripción de Red Hat. Los fallos en seguridad pueden darse en cualquier pieza de software (o más allá del software, como bien nos ha mostrado el 2018). Cuando sucede, Red Hat se compromete a entregar tan rápido como es posible tanto los parches a los clientes como a corregirlo en proyectos de código abierto relacionados.
Lanzamos un aviso de seguridad crítico y parches para CVE-2018-1002105, un fallo en la escalada de privilegios que afecta a Kubernetes. El error del escalado de privilegios de Kubernetes es un ejemplo de cómo Red Hat ayuda a afrontar la seguridad del software tanto a nivel de la comunidad como a nivel empresarial, especialmente cuando las organizaciones en todo el mundo buscan apoyarse en tecnologías emergentes como es Kubernetes para ayudar a impulsar la transformación digital. Como estándar de facto en la orquestación de contenedores de Linux, Kubernetes hace posible organizar conjuntamente las aplicaciones en contenedores, permitiendo servicios compuestos que comprenden cientos, o incluso miles, de servicios "más simples". Estas aplicaciones orquestadas suelen ser más fáciles de gestionar, más ágiles y sencillas de mantener que las aplicaciones tradicionales.
Pero Kubernetes, como todo software, no es inmune a los problemas de seguridad, el fallo del escalado de privilegios hace posible que cualquier usuario obtenga todos los privilegios de administrador en cualquier nodo que se ejecute en un clúster de Kubernetes. Esto es un gran problema. Este usuario no solo puede robar datos confidenciales o introducir un código malicioso, sino que también puede reducir las aplicaciones de producción y servicios desde dentro del firewall de una empresa.
Es importante tener en cuenta que SE HAN VISTO AFECTADOS TODOS LOS SERVICIOS Y PRODUCTOS BASADOS EN KUBERNETES (entre los que se incluyen Red Hat OpenShift Container Platform, Red Hat OpenShift Online y Red Hat OpenShift Dedicated). Red Hat ha comenzado a proporcionar parches y actualizaciones de servicio a los usuarios afectados, permitiéndoles resolver este fallo inmediatamente o en el momento que mejor se ajuste a su perfil de riesgo específico. Es posible encontrar una descripción más detallada del error del incremento de privilegios de Kubernetes desde aquí.
Esta solución es el resultado del esfuerzo de la comunidad de Kubernetes y contribuyentes líderes como Red Hat. Pero incluso el hecho de ser capaces de parchear un fallo tan grave revela una realidad desagradable, una que Paul Cormier ya mencionó hace unos meses: que cuando se trata de la seguridad del código abierto, el debate sobre el producto/proyecto es importante, especialmente para los sistemas de misión crítica.
Si bien la comunidad de Kubernetes subió el parche correspondiente a tiempo de forma oportuna, simplemente tener a mano los bits no aborda necesariamente otros factores que se vieron afectados por el fallo. ¿Qué pasaría si los sistemas de producción están ejecutando puntos de integración específicos o cargas de trabajo que se ven afectadas de forma adversa por el parche? O, ¿qué sucedería si al aplicar el parche se provoca sin querer un impacto en el rendimiento de un sistema de producción o, peor aún, un tiempo de inactividad?
Aquí es donde los productos de código abierto pueden separarse por sí mismos de los proyectos. Red Hat cuenta con décadas de experiencia ofreciendo productos de código abierto, desde el código de protección para los requisitos empresariales hasta la entrega de soluciones para vulnerabilidades y fallos. Como proveedor líder mundial de soluciones de código abierto empresarial, sabemos cómo solucionar problemas como este, al igual que supimos cómo corregir Spectre, Meltdown, Dirty COW y otra serie de fallos anteriores. Parte de esta experiencia es ser conscientes de que no es suficiente impulsar una solución, es necesario ofrecer a nuestros clientes la documentación y estrategias que les ayuden a evaluar cómo les ha afectado, qué sistemas se están viendo impactados y por qué (o por qué no) deben aplicar las correcciones.
Este es el listón que se ha autoimpuesto Red Hat, primero con Linux en la organización y ahora con Kubernetes a nivel empresarial. A medida que Kubernetes se hace más notable para las empresas en su camino a la transformación digital, es lógico pensar que se descubrirán más fallos dentro de la tecnología. La comunidad estará lista para corregir el código, mientras que Red Hat estará preparada para ayudar a reparar los sistemas críticos de la manera que tenga más sentido acorde con las necesidades concretas de las empresas.
Por Ashesh Badani, VP/GM, Cloud Platforms BU, Red Hat
