El flujo de trabajo DevOps se caracteriza por ciclos de lanzamiento rápidos que requieren un código probado con rapidez. Esto se consigue dando a los desarrolladores la posibilidad de poner en marcha rápidamente nuevas máquinas virtuales, normalmente basadas en plantillas, en las que pueden ejecutar esas pruebas. Esto se controla con scripts, utilizando al menos una de las múltiples herramientas de automatización disponibles, como ansible o puppet.

Los desarrolladores suelen poner en marcha nuevas máquinas virtuales para probar, compilar y publicar nuevo código, pero rara vez son conscientes de que esas máquinas virtuales pueden ser el objetivo de actores maliciosos, incluso si son de corta duración. El hecho de que un sistema de este tipo se vea comprometido puede suponer un trampolín para acceder a activos internos que, de otro modo, serían inaccesibles. Esto ha sido un hecho conocido desde al menos 2015, cuando el tema se discutió en un Black Hat Europe 2015, con el título apropiado de "Intrusión continua: Por qué las herramientas de IC son las mejores amigas de un atacante", y aun así se sigue restando importancia e ignorando el riesgo.

Con este artículo, puede aprender a integrar la implantación de KernelCare en el flujo de trabajo para que incluso esos sistemas se mantengan actualizados con los últimos parches del kernel.

Máquinas virtuales DevOps

DevOps utiliza la virtualización para ayudarles a tener despliegues rápidos y estables. "La virtualización es el proceso de creación de software que imita diversos entornos de hardware y software sin tener que cambiar el propio hardware físico"(BMC). Una máquina virtual está pensada para funcionar como una simulación de una configuración específica de hardware o software, lo que permite a DevOps probar diferentes aspectos de software o hardware sin tener que cambiar ningún componente físico; también pueden ejecutar varias simulaciones a la vez, lo que acelera el proceso.

Cuestiones de seguridad

Las máquinas virtuales se basan en plantillas creadas en algún momento y, cuando se ponen en línea, no suele haber ningún proceso de actualización, por lo que cualquier vulnerabilidad que existiera en el momento de la creación o cualquier vulnerabilidad que haya aparecido desde esa creación estará en la máquina virtual que se ponga en línea. Este riesgo se ve minimizado por la corta vida útil habitual de estas máquinas virtuales.

"Se puede tomar una instantánea de una máquina virtual y grabarla en disco, para no tener que volver a crearla la próxima vez, o para la recuperación de desastres. Basta con disparar una de estas máquinas virtuales que se encuentran en bibliotecas sin conexión. Pero, en su mayor parte, no se mantienen actualizadas con firmas y parches A/V", afirma Neil MacDonald.

Estas máquinas virtuales suelen ser máquinas virtuales "desechables". Se ponen en marcha, se utilizan para pruebas y se borran u olvidan. El problema es que estas máquinas virtuales siguen siendo técnicamente servidores, y si no se parchean y mantienen, las vulnerabilidades que existían cuando se crearon siguen ahí, lo que significa que son objetivos fáciles para los hackers. Aunque deberían comprobar si hay parches o vulnerabilidades, a menudo no lo hacen, por lo que estas plantillas son un riesgo inminente.

Los piratas informáticos han identificado este posible agujero en la seguridad y pueden acechar la aparición de las máquinas virtuales para atacarlas durante ese tiempo. Estas pueden ser justo el punto de entrada al resto de la infraestructura porque estas máquinas virtuales requieren acceso a bases de datos, otros sistemas internos o mecanismos de autenticación.

¿Qué es DevSecOps?

La definición sencilla de DevSecOps es que añade seguridad al desarrollo y las operaciones. Añade el objetivo de implementar la seguridad en la canalización de DevOps para garantizar que todo se mantiene a salvo y seguro. Cambiar una organización hacia el seguimiento de un marco DevSecOps puede ser difícil, ya que a menudo requiere un trabajo adicional de supervisión de la información en las máquinas virtuales. Sin embargo, KernelCare ofrece parches en vivo para que no tenga que hacer ningún trabajo extra para ayudar a que los sistemas sean más seguros y protegidos. Nuestro sistema se encargará de todo por usted en lo que respecta a los parches de seguridad del kernel y las bibliotecas compartidas.

Solución KernelCare DevSecOps

Dado que la seguridad y la aplicación de parches en tiempo real son importantes para el proceso DevOps, se necesita una solución sencilla: KernelCare. KernelCare cuenta con un sencillo procedimiento de instalación que puede automatizarse e incluirse en los scripts de despliegue de las máquinas virtuales. De este modo, cuando se pongan en línea, KernelCare parcheará en vivo el kernel y/o las bibliotecas compartidas y ayudará a hacerlos más seguros, por breve que sea su vida útil. Esto también garantiza que todas las instantáneas que haga de las máquinas virtuales se parchearán cuando se pongan en línea, por lo que no tendrá que preocuparse de que antiguas vulnerabilidades dejen puertas abiertas a los piratas informáticos para entrar en sus sistemas.

Si la empresa utiliza contenedores en lugar de máquinas virtuales, entonces instalar KernelCare en el host del contenedor. De esta forma, podrá tener todos sus contenedores protegidos sin necesidad de reiniciar el host en ningún momento para aplicar parches de seguridad y sin tiempo de inactividad.

En el proceso DevOps, la integración descrita aquí se produce entre las fases de compilación y prueba.

Integración de KernelCare en sus sistemas

Para integrar KernelCare con Ansiblenecesita la siguiente información:

• " Nombre del servidor ePortal (o IP) en la variable Ansible eportal srv. Otras opciones del archivo de configuración se pueden encontrar en Config Options y KernelCare client config file (ePortal).
• " Una clave de activación en la variable Ansible activation_key. Las claves de activación se pueden generar en ePortal como se describe en Gestión de claves (ePortal).

Para integrar KernelCare con Puppet, siga las instrucciones del vídeo enlazado.

Un ejemplo de código para integrar KernelCare en su sistema es:

- anfitriones: kernelcare

  vars:

       eportal_srv: http://192.168.250.19

       activation_key: 89gRVCp1rY0ZQ053

tareas:

- name:Descargar el shell script de instalación

       get_url:

       url: “{{ eportal_srv }}/installer”

       dest: /root/kc-install.sh

       modo: '0700'

- name:Ejecutar el shell script de instalación

       shell: /root/kc-install.sh >> /var/log/kcare_install.log

       medio ambiente:

       KCARE_REPO: “{{ eportal_srv }}/repo”

- name:Actualizar kcare.conf con la configuración de ePortal

       archivo de bloqueo:

       ruta: /etc/sysconfig/kcare/kcare.conf

       crear: sí

       bloque: |

       PATCH_SERVER={{ eportal_srv }}/

       REGISTRATION_URL={{ eportal_srv }}/admin/api/kcare

- name:registrar agentes KernelCare

       command: /usr/bin/kcarectl –register {{ activation_key }}

Conclusión

Con KernelCare, cualquier parche se instalará durante la fase de despliegue de su canalización DevOps, sin esfuerzo adicional para los desarrolladores al crear máquinas virtuales. Dispondrá de un entorno más seguro para sus pruebas. Esto, a su vez, conducirá a un entorno interno más seguro. KernelCare es un paso en la dirección correcta, que le ayudará a convertir sus DevOps en DevSecOps. KernelCare live patching puede integrarse fácilmente en los scripts de despliegue de nuevas máquinas virtuales y, de este modo, hacerlas más resistentes frente a las vulnerabilidades; con KernelCare, obtendrá más seguridad sin trabajo adicional.