Comunidad Blogger

Falla en los privilegios de Kubernetes: La innovación aún necesita de la experiencia en seguridad de la TI

Ashesh Badani, Director de la Unidad de Negocio de Cloud Platforms en Red Hat

La seguridad de la TI es importante en todos los niveles de tecnología en la empresa, desde la base de la infraestructura hasta las aplicaciones y servicios críticos de cara al usuario final. Esta necesidad persiste independientemente de que la tecnología sea de vanguardia. En pocas palabras, la seguridad de la TI siempre es importante.

Para el software de código abierto que frecuentemente impulsa las innovaciones de las organizaciones modernas tales como las tecnologías Linux, nube híbrida, contenedores y Kubernetes, este equilibrio entre la innovación, la seguridad y la estabilidad es un aspecto significativo del valor que puede ofrecer una suscripción de Red Hat. Las fallas de seguridad pueden ocurrir en cualquier componente del software (o más allá del software, como hemos aprendido este año con Meltdown y Spectre en los procesadores). Cuando ocurren, Red Hat está comprometida a entregar lo más rápido posible tanto los parches para el cliente como las correcciones a los proyectos open source en desarrollo.

Apenas lo descubrimos, emitimos un Aviso de Seguridad crítica y parches para CVE-2018-1002105, una falla en la escalada de privilegios que afecta a Kubernetes. Esta falla es un ejemplo de cómo Red Hat ayuda a enfrentar la seguridad del software tanto a nivel de la comunidad como de la empresa, particularmente en organizaciones de todo el mundo que buscan apoyarse en tecnologías emergentes como Kubernetes para ayudar a impulsar la transformación digital. Kubernetes —el componente estándar en la orquestación de contenedores de Linux— hace posible orquestar aplicaciones contenerizadas en conjunto, habilitando servicios compuestos formados por cientos o hasta miles de servicios “más sencillos”. Estas aplicaciones orquestadas por lo general son más fáciles de gestionar, más ágiles y más simples de mantener que las aplicaciones tradicionales.

Pero Kubernetes, como todo software, no es inmune a los problemas de seguridad. Esta falla actual hace posible que cualquier usuario adquiera privilegios de administrador plenos en cualquier nodo informático que se ejecute en un grupo de contenedores (pod) de Kubernetes. Esto es muy importante. Esta persona no sólo podría robar información confidencial o inyectar un código malicioso sino que también podría desbaratar aplicaciones y servicios de producción desde adentro de una organización.

Es importante destacar que todos los servicios y productos basados en Kubernetes se ven afectados, incluidos Red Hat OpenShift Container Platform, Red Hat OpenShift Online y Red Hat OpenShift Dedicated. Red Hat ha comenzado a entregar parches y ha impulsado actualizaciones de los servicios para los usuarios afectados, lo cual les permite hacer frente a esta falla en forma inmediata o cuando mejor les convenga según su nivel de riesgo específico. Encontrará información más detallada de la falla en la escalada de privilegios de Kubernetes aquí.

Este parche es el resultado de los esfuerzos de la comunidad de Kubernetes y de colaboradores líderes como Red Hat. Pero este acto de corregir una falla de esta gravedad pone de manifiesto una realidad crítica que Paul Cormier anunció hace pocos meses: Cuando se trata de la seguridad del código abierto, el debate sobre producto versus proyecto es importante, en especial para sistemas críticos para la misión.

Si bien la comunidad de Kubernetes entregó el parche desarrollado a tiempo, puede que no resuelva necesariamente los otros factores afectados por la falla. ¿Qué sucede si sus sistemas de producción ejecutan puntos de integración o cargas de trabajo especializados que se ven adversamente afectados por el parche? ¿Qué ocurre si la aplicación del parche repercute inesperadamente en el rendimiento o, incluso peor, provoca tiempo improductivo?

Es aquí donde los productos de código abierto pueden separarse de los proyectos. Red Hat posee décadas de experiencia en la provisión de productos open source, desde el fortalecimiento del código en respuesta a los requerimientos de la empresa hasta la entrega de parches para vulnerabilidades y fallas. Como proveedor líder mundial de soluciones de código abierto, sabemos cómo corregir esta clase de problemas así como supimos cómo corregir Spectre, MeltdownDirty COW una cantidad de fallas distintas anteriores a ellos. Parte de esta experiencia consiste en saber que no basta con proveer un parche. Necesitamos dotar a nuestros clientes de documentación y estrategias que los ayuden a evaluar cómo se ven afectados, qué sistemas han sido impactados y por qué (y hasta por qué no) deberían aplicar los parches.

Esta es la expectativa que Red Hat estableció, primero con Linux y ahora con Kubernetes de grado empresarial. A medida que Kubernetes se hace mucho más presente en las empresas que persiguen la transformación digital, es lógico pensar que se irán descubriendo más fallas en la tecnología. La comunidad estará preparada para corregir el código y Red Hat estará preparada para ayudarlo a restablecer sus sistemas críticos de la manera que mejor se adecue a sus necesidades organizacionales particulares.

Yesica Flores

Soy Yes, blogger desde hace más de 5 años. Me he especializado en el viejo y olvidado arte de divagar. Contacto [email protected]

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.