Por qué es importante utilizar containers en IAM legada?

En los últimos años, las organizaciones medianas y grandes han tenido que pasar por una transformación significativa para ser más competitivas. Una de las líneas de acción más ambiciosas ha sido mejorar la eficiencia operativa mediante la «migración a la nube», es decir, aprovechar las aplicaciones, las plataformas y la infraestructura como servicio.

La infraestructura de identidad heredada me recuerda al «elefante en la habitación». Sabes que está ahí, ocupa mucho espacio y requiere mucho esfuerzo gestionarla. En el día a día, te gustaría evitarlo, pero andar de puntillas y hacer adaptaciones constantemente solo para que funcione es cada vez menos factible. La mayoría de las infraestructuras de identidad antiguas se alojan en las instalaciones o en nubes privadas, y se ejecutan sobre servidores básicos o plataformas de virtualización de hardware, como vSphere de VMware y otras. Empaquete ese pesado (pero necesario) código de software con solo las bibliotecas del sistema operativo (SO) y las dependencias que requiere en un solo ejecutable ligero que se ejecute de manera uniforme en cualquier infraestructura, y tendrá un «contenedor». Más portátiles que una máquina virtual (VM), los contenedores que ahorran recursos son una tecnología probada y omnipresente, y una excelente manera de hacer frente a ese problema de infraestructura y facilitar el camino hacia la modernización de la IAM.

Pero empecemos por el principio. En esta publicación, analizaré algunos enfoques típicos de la migración incremental a la nube y explicaré cómo estos enfoques son insuficientes en el contexto de la migración de los servicios de identidad y autenticación.

Aplicaciones empresariales que «levantan y cambian»

Las aplicaciones empresariales se combinan con la infraestructura de identidad heredada, como Active Directory, y los productos que se acercan al final de su vida útil (EOL). Si bien es posible solucionar lo primero con las herramientas de migración ofrecidas por el proveedor de la nube (Azure para Active Directory), esto no funciona con los productos de EOL. La adopción de un enfoque de «cambiar y cambiar» para las aplicaciones empresariales, con la expectativa de que funcionen correctamente con una infraestructura de identidad más moderna, es una receta para el fracaso. Los ecosistemas de TI de los que dependen ya no existen o, si existen, no cumplen con los requisitos de integración de esas aplicaciones empresariales. Entonces, ¿cómo podemos trasladar nuestras aplicaciones empresariales de forma eficaz y exitosa a un entorno de nube moderno?

Infraestructura de identidad heredada que «levanta y cambia»

Dado que no podemos simplemente esperar que nuestras aplicaciones empresariales funcionen en el nuevo entorno, una idea es «elevar y trasladar» nuestra infraestructura de identidad heredada a la nube tal cual, de modo que todo coincida con nuestra configuración anterior y, al mismo tiempo, funcione más allá del perímetro. En la práctica, esto se traducirá en configurar varias máquinas virtuales en la infraestructura como servicio (IaaS) elegida, como AWS o Azure, para alojar una réplica de nuestra infraestructura de identidad heredada. Esto no es tan fácil como parece, ya que tendremos que crear una imagen instantánea de las máquinas virtuales existentes (si estamos virtualizando) y portarlas al hipervisor que utilice el proveedor de servicios en la nube. Una vez que podamos ejecutar la infraestructura de identidad en la nube, la configuración se verá afectada, ya que los cambios en el entorno no pueden aislarse por completo. Por lo general, se producen mediante algún tipo de interfaz de usuario de administración o mediante descriptores de configuración, lo que no coincide con las oportunidades de automatización.
‍
Una vez que todo esté funcionando correctamente, ¿cómo podemos hacer que el trabajo de aprovisionamiento de una infraestructura de identidad que funcione sea repetible y reproducible, para aprovechar la automatización?

Adopción de la infraestructura como código

Echemos un vistazo a la definición de infraestructura en Wikipedia como código:

La infraestructura como código (IaC) es el proceso de administración y aprovisionamiento de centros de datos informáticos a través de archivos de definición legibles por máquina, en lugar de herramientas de configuración interactivas o de configuración de hardware físico. [1] La infraestructura de TI gestionada mediante este proceso comprende tanto equipos físicos, como servidores físicos, como máquinas virtuales y los recursos de configuración asociados.

Por lo general, esto se implementa codificando secuencias de comandos de acciones de aprovisionamiento de infraestructura, archivos de configuración o ambos. Hay muchos paquetes de código abierto de buena calidad que se pueden usar para esto, como Packer, Terraform y Ansible, por nombrar algunos. Al adoptar este enfoque, podrá implementar gradualmente la configuración de la infraestructura de identidad de forma rápida y uniforme.

Si bien la mayoría de las organizaciones ya aprovechan este método para la TI de su línea de negocio, aplicarlo a la infraestructura de identidad heredada plantea algunos desafíos:

• La infraestructura de identidad se implementó manualmente (probablemente mediante una interfaz gráfica de usuario) hace al menos 10 o 15 años, antes de que la infraestructura como código (IaC) existiera. Por lo tanto, los tipos de configuraciones detalladas que se aplicaron originalmente no están disponibles, lo que a su vez requiere que se les aplique ingeniería inversa.
• Hay muchas piezas móviles: el middleware, los servicios de autenticación y autorización y los directorios, por nombrar algunos; cada uno de ellos tiene una presencia significativa y un estrecho acoplamiento.
• Aunque la mayoría de las acciones de configuración se pueden realizar desde la interfaz de línea de comandos (CLI), otras no, lo que nos obliga a tener que trabajar con API de productos de bajo nivel, lo que aumenta la complejidad.

Es posible que el uso exclusivo de máquinas virtuales (VM) remotas no sea suficiente

Es probable que la mayoría de las organizaciones con un ecosistema de TI relativamente complejo migren sus máquinas virtuales locales a máquinas basadas en la nube, ya que la combinación es individual. Sin embargo, con los productos de identidad antiguos, normalmente se necesitará más de una máquina virtual. Por ejemplo, con una implementación típica de CA Siteminder, habrá una máquina virtual para el servidor proxy seguro (SPS), otra para el servidor de políticas, otra para el almacén de políticas y otra para la interfaz de usuario de administración. Suponiendo que se espera que los servicios de identidad tengan una alta disponibilidad y sean escalables, será necesario asignar al menos una máquina virtual más por cada componente.

Incluso con un enfoque de IaC, crear imágenes de máquinas virtuales, luego girarlas y mantenerlas tendrá un impacto negativo en la factura de la infraestructura de la nube, sin mencionar que dificultará el consumo de la infraestructura de IAM por parte de los desarrolladores de software y el personal de DevOps. Operar entornos de ensayo y desarrollo independientes aumentará la carga y los costos de mantenimiento en un orden de magnitud. Además de los entornos de producción, los entornos restantes solo se consumirán de forma ocasional y, con el tiempo, dejarán de funcionar; sin embargo, dado que la infraestructura aún está asignada, habrá que pagar el precio total.

Entonces, ¿cómo podemos reducir el espacio que ocupa nuestra infraestructura de nube y reducir los costos asociados? ¿Cómo podemos aumentar la agilidad para que nuestros servicios de identidad antiguos estén más fácilmente disponibles para los consumidores, como los desarrolladores y los equipos de DevOps?

Reducir el tamaño del elefante: contenedores al rescate

La tecnología de contenedores se considera un avance significativo. Mejora la eficiencia y la portabilidad, al tiempo que reduce los gastos generales de la virtualización tradicional. Los contenedores Docker, en concreto, son omnipresentes. Dado que todos los principales proveedores de IaaS de nube pública son compatibles con Docker, las organizaciones pueden reducir los costos y la complejidad y, al mismo tiempo, dejar que el proveedor de la nube se encargue de la infraestructura. En lugar de sortear con tanta ligereza los enormes obstáculos que suponen las enormes aplicaciones heredadas, podemos usar Docker para contenedorizarlas y transportarlas fácilmente a un entorno en el que puedan resultar útiles.

¿Qué nos aporta esto en términos de nuestra migración de IAM a la nube?

En primer lugar, una sola máquina virtual puede ejecutar cualquier cantidad de contenedores. Por lo tanto, podríamos asignar una máquina virtual para ejecutar todos nuestros entornos de ensayo, pruebas y desarrollo, y una segunda para la producción. En lugar de tener una máquina virtual dedicada por cada servicio de IAM, ahora simplemente utilizamos contenedores, lo que promueve la optimización de los recursos y la mejora de los costos, ya que los contenedores comparten recursos (por ejemplo, un sistema operativo) con el host.

En segundo lugar, los equipos de desarrollo y DevOps ahora pueden ejecutar una réplica de una infraestructura de identidad heredada completa en su nube preferida o incluso en su propia estación de trabajo.

En tercer lugar, ya que hacer girar una imagen de Docker es muy rápido (¡puede tardar menos de un segundo!) Una vez que hayamos terminado, por ejemplo, de probar la integración del inicio de sesión único (SSO) con los servicios de autenticación antiguos que se ejecutan en la nube, podemos continuar y desmantelar el entorno. Esto significa que no habrá facturas por la capacidad no utilizada y que habrá más recursos disponibles para otros servicios de IAM en contenedores.

Por último, su infraestructura de identidad heredada puede alinearse desde el primer día con sus esfuerzos de DevOps y el ciclo de vida de desarrollo de software (SDLC). No es necesario completar la modernización de la IAM para empezar a ver los beneficios. La habitación parece mucho más espaciosa sin ese elefante en el medio, ¿verdad?

‍

¿Cómo puedes empezar?

En nuestra próxima entrada de blog, le guiaremos por el proceso de habilitar la infraestructura como código y la contenedorización con CA Siteminder.