Mitos y verdades sobre la seguridad en Red Hat OpenShift
Muchos de nuestros clientes están planeando empezar a usar Red Hat OpenShift, nuestra plataforma de orquestación de contenedores predilecta. Sus ventajas se pueden resumir en que permite una una progresiva modernización de las aplicaciones existentes y el despliegue de muchas otras que, para qué negarlo, con un diseño basado en micro-servicios se van imponiendo en muchas las nuevas arquitecturas de TI. El solo hecho de pensar en no tener que “preparar” nunca más una máquina (instalar sistema operativo, configurar red, seguridad, instalar librerías y software dependiente) cada vez que queremos desplegar un entorno justifica darle una oportunidad a esta tecnología.
Kubernetes es a los contenedores lo que OpenStack fue a los entornos Cloud. Una solución de código abierto, que permite compartir una parte de la infraestructura disponible en nuestros centros de datos: servidores, redes, almacenamiento en pools de recursos sobre los que desplegar, de manera automática diversas cargas de trabajo. A través de un portal de auto-provisionamiento, nuestros desarrolladores podrán no solo desplegar los entornos que necesiten para que sus aplicaciones funcionen perfectamente, sino también comprobar de manera automática y de manera continua, que esas aplicaciones funcionan correctamente. Si el “commit” de un desarrollador a última hora del día, provoca un fallo, se puede volver a la versión del día anterior sin que nadie tenga que intervenir.
Si a esto le sumamos la capacidad de hacer despliegues paulatinos, donde un porcentaje pequeño de los usuarios disfruten de una nueva versión de nuestra aplicación mientras el resto siguen utilizando la última versión estable; una alta disponibilidad que funciona sin ninguna configuración adicional, la asignación de recursos (desarrolladores, memoria, CPU, espacio en disco, asignación de direcciones IP) por proyecto o la capacidad de medir en tiempo real qué parte de nuestra infraestructura estamos usando, con qué nivel de eficiencia y con qué resultados, pocos responsables de sistemas dirán que no a semejante maravilla. Sin olvidarnos de la posibilidad de escalar automáticamente las aplicaciones añadiendo o eliminando contenedores según se necesite.
Por suerte o por desgracia, ya no todo está en la mano de los responsables de sistemas. ¿Qué ocurre con la seguridad? ¿Qué opinan los CISOs? Toca repasar algunos “mitos”.
OpenShift es tremendamente seguro por diseño. En nuestra opinión, su tecnología básica (los contenedores) es tan segura, como lo sea el Kernel de Linux en cada momento. Es decir, los procesos de los contenedores están separados por “namespaces” del kernel de linux, los recursos que usan por “cgroups” y la seguridad de los mismos y su contexto por SELinux. Es potente, si, pero no dejamos de estar compartiendo en cada uno un kernel entre muchos contenedores.. y el kernel hay que parchearlo, también por motivos de seguridad. La inclusión de RHCOS (Red Hat Core OS) nos ha permitido avanzar mucho en estos últimos tiempos en cuanto a la seguridad del sistema operativo sobre el cual corre esta distribución de Kubernetes. Ahora bien, dado que los nodos del RHCOS están destinados a funcionar sin apenas cambios, es importante que cualquier mejora relacionada con la seguridad de esos nodos se haga con extremado cuidado.. no vaya a ser que consigamos el efecto contrario.
Las imágenes que descargamos están siempre verificadas y su código auditado por Red Hat. Bueno, en realidad el acceso a las imágenes de contenedor (descargadas o propias) se gestionan de manera similar a los RPMs. Existe repositorios públicos o privados a los que nos conectamos, con sus claves y sus firmas. Las vulnerabilidades siguen saliendo todos los días así que necesitamos tener algún tipo de solución que supervise los contenidos de las imágenes de contenedor disponibles en nuestros repositorios, en especial las imágenes descargadas e instaladas en nuestro entorno.
OpenShift es compatible con Artifactory de JFrog, Black Duck Hub y Docker Trusted Registry. También se puede usar Red Hat CloudForms SmartState para marcar las imágenes vulnerables de tal manera que OpenShift evite que esas imágenes sean usadas. También son útiles para las aplicaciones que realizan pruebas de seguridad de aplicaciones estáticas (SAST) y pruebas de seguridad de aplicaciones dinámicas (DAST), como HP Fortify y IBM AppScan.
OpenShift tiene un sistema de autenticación robusto y seguro. En realidad cada cluster de OpenShift usa cuentas de usuarios, grupos y roles.
Para gestionar el acceso que cada usuario tiene a los componentes de OpenShift y ser capaz de verificar la identidad de cada usuario, el cluster se conectará a diferentes proveedores de identificación (OpenID, LDAP, Active Directory, Github, etc). Cada uno de los cuales tendrá su propia configuración, ventajas e inconvenientes.
El aislamiento de redes y comunicaciones entre proyectos de OpenShift es suficiente. Es robusto, pues está basado en los componentes de red de Kubernetes, pero existen operadores y plug-ins que nos pueden ayudar a aislar las diferentes redes o dar accesos dedicados a ciertas tarjetas de red usando tecnologías como SR-IOV. Plugins como Multus-CNI que permiten esta y otras funciones, complementando las características del Operador de Red del Clúster (CNO), los CNI’s “Container Network Interfaces” y CoreDNS .
¿Te interesa saber más sobre OpenShift? Quizás te interese nuestro curso de Red Hat OpenShift 4.X en formato intensivo de tres días. También ofrecemos formación oficial de IBM si lo que quieres es desplegarlo servidores IBM Power Systems.
IBM 
