En el mundo DevOps la automatización es uno de los pilares fundamentales y básicos, de hecho, se habla de “automatizar todo y automatizar siempre” como principio clave para la evolución y madurez de los modelos DevOps aplicados.
La Integración Continua automatiza la ejecución de pruebas de calidad sobre el código entregado, su compilación, la ejecución de pruebas unitarias y hasta podríamos depositar el binario creado en un repositorio de artefactos (además de realizar las notificaciones que correspondan según avance el procesamiento y obtener los resultados).
Podríamos necesitar desplegar el binario generado (Entrega Continua), teniendo como opciones el despliegue sobre infraestructura existente, o podríamos aprovisionar un IaaS sobre el que configurar nuestro plataformado (un PaaS específico, el de la aplicación o componente que acabamos de construir).
Y es en estos supuestos donde aparecen como alternativas a la ejecución manual a través de consolas la Infraestructura como Código (IaC) y la Configuración como Código (CaC) . Estas soluciones están pensadas para que funcionen desde el repositorio de código fuente, pudiendo (o debiendo) acompañar a las entregas de los equipos de desarrollo. Se programan, es decir, hacen uso de ficheros de texto plano en los que se incluyen descripciones e instrucciones que son entendibles por la herramienta de automatización que elijamos (Terraform, Ansible, etc.) para así poder automatizar el aprovisionamiento, configuración y despliegue, o en sentido contrario, la desinstalación, reconfiguración y desaprovisionamiento.
En definitiva, permiten automatizar procesos que cuentan casi siempre con una cierta complejidad y que normalmente se podrían repetir con mucha frecuencia (hasta varias veces al día). Intentar asumir su ejecución de forma manual es poco eficiente y desaconsejable en líneas generales.
Visto esto, ¿cómo podemos diferenciar más claramente estas soluciones de automatización?:
-
IaC engloba herramientas que gestionan componentes a nivel de infraestructura (aprovisionan, organizan, desaprovisionan) en definitiva, focalizadas en el IaaS.
-
CaC engloba herramientas que se encargan de gestionar la configuración de entornos, de modo que facilitan el pase entre entornos de aplicaciones o componentes, su instalación, actualización, modificación o desinstalación.
Ejemplos de herramientas IaC pueden ser Terraform, CloudFormation (AWS) o Azure Resource Manager, mientras que de CaC puede ser Ansible, pero ojo, Ansible podría clasificarse también como una herramienta mixta pues se solapa a nivel funcional con las demás.
La experiencia indica que en general estas automatizaciones alcanzan tanto la parte de IaC como de CaC, y lo mejor es aprovechar lo mejor que nos ofrecen estas herramientas en cada caso.
-
Desde el punto de vista operativo, algunas opciones ofrecen mayores ventajas en modelos multicloud (como por ejemplo Terraform) frente a otras más acopladas a un proveedor o fabricante (CloudFormation, Azure Resource Manager). También se podría destacar la posibilidad de operar de forma centralizada, tanto en on-prem o en cloud. Ejemplos de esto último pueden ser Terraform Cloud/Enterprise y Ansible Tower.
-
Desde el punto de vista del licenciamiento, Ansible y Terraform disponen tanto de versiones de Comunidad como de versiones que cuentan con soporte por parte de cada fabricante.
Podemos plantear modelos de automatización que hagan uso de más de una herramienta a la vez, por ejemplo: con Terraform definimos un plan de ejecución en el que describimos todo lo que hay que hacer para conseguir el estado deseado (por ejemplo un aprovisionamiento) para luego invocar a Ansible (como provisioner) para que se ejecute en el recurso aprovisionado.
Existe también la opción de plantear este modelo de forma inversa, ya que desde Ansible podemos hacer uso de su módulo para ejecutar Terraform (terraform plan, apply, destroy).
Toda automatización es buena, aunque no deja de estar expuesto al mismo tipo de problemas que los modelos manuales: el fallo humano. En ambos casos (manual y automatizado) suponen un reto frente a configuraciones que no se han pensado o definido bien, por ejemplo:
-
Grupos de seguridad a null (que podrían abrir y permitir el acceso a través de un rango de puertos no deseado),
-
No hacer uso de Usuarios, Roles o Perfiles específicamente creados y que tienen aplicadas políticas de seguridad específicas,
-
No incluir la infra creada dentro del modelo de monitorización.
-
No “taggear” correctamente los recursos.
-
etc.
Además de los problemas anteriores, bien por inexperiencia o bien por falta de un catálogo de buenas prácticas, podemos encontrar problemas añadidos gestionando secretos, de entre los que podemos destacar:
-
Acceso a certificados para conectar vía ssh (Private Key / Private Key Passphrase) y que no deben aparecer nunca “hardcodeados” en código.
-
Uso de credenciales de acceso al proveedor cloud, que de igual forma tampoco pueden aparecer “hardcodeadas” y que deben ser securizadas correctamente.
-
Asignación de privilegios de escalado a usuarios que no deberían tenerlos.
Y ya que hablamos de código, no olvidemos problemas específicos trabajando con repositorios de código fuente:
Existen multitud de herramientas que nos ayudan a dormir mejor (ojo que hay que leer con detenimiento cómo funcionan antes de lanzarse a por ellas 😊)
Consecuencia de este tipo de situaciones, existen tendencias como Zero Trust que suponen un nuevo paradigma en la forma que protegemos nuestros datos e identidades (Secretos). Conceptualmente aplican el criterio de “nunca confíes, has de verificar siempre” y para garantizar una seguridad efectiva hacen uso de plataformas de identidad unificadas, como por ejemplo HashiCorp Vault:
Zero-Trust se basa en asegurar todo en identidades de confianza con cuatro tipos de controles fundamentales:
-
La autenticación y autorización de máquinas.
-
El acceso de máquina a máquina.
-
La autenticación y autorización de personas.
-
El acceso de persona a máquina.
En definitiva, las ventajas que ofrece la IaC son muchas, pero no podemos perder de vista los riesgos que también conlleva y frente a los que tendremos que adaptar nuestras arquitecturas o bien hacer uso de herramientas que nos permitan asegurar la ausencia de determinadas casuísticas.
Ejemplos de soluciones de IaC tenemos AWS CloudFormation, Red Hat Ansible Automation, Hashicorp Terraform y HashiCorp Vault, y a todos estos fabricantes y sus soluciones los podremos ver en la próxima edición del DevOps Spain III. ¡Mira lo que pasó en la tercera edición!.
