Bienvenidos de nuevo, en esta entrega vamos a abordar el despliegue de nuestros entornos a una escala empresarial y agregaremos características como protección a nivel de red, aseguramiento y trazabilidad de las sesiones conectadas a nuestros IDEs, e incluso dejaremos la puerta abierta para seguir explorando y experimentando con estos servicios.

Recordemos el escenario para el despliegue, un ambiente usando AWS Systems Manager para la conexión. En este escenario los grupos de seguridad no tendrán reglas de entrada y a través del agente de SSM se garantiza la comunicación entre cloud9 y la instancia de Amazon EC2 administrada.

Antes de pasar a la demostración repasemos un par de conceptos respecto a AWS Systems manager y el uso de Session manager. Session Manager nos ofrece una manera segura y auditable para acceder a los nodos de cómputo, no solo puede usarse para Amazon EC2, sino que también para servicios como Fargate y CodeBuild, adicionalmente:

• Es compatible con sistemas operativos Linux y Windows.
• Elimina la necesidad de crear bastion hosts, agregar excepciones al firewall y gestionar claves SSH.
• Centraliza los controles de acceso via IAM.
• Permite guardar la actividad de la sesión y enviar los registros a Amazon Cloudwatch logs, S3 y/o CloudTrail.
• Mejora la postura de seguridad en cuanto a la gestión de instancias al usar VPC interface endpoints y evitar que la comunicación salga a internet.
• Permite la investigación y la corrección a los equipos DevOps y solución de incidentes por medio de un acceso instantáneo y seguro.

Demostración – Ambiente donde usando la conexión mediante AWS Systems Manger

Este escenario usaremos los siguientes servicios:

• AWS Cloud 9: es un IDE basado en la nube que le permite escribir, ejecutar y depurar su código a través de un navegador.
• AWS CodeCommit: es un servicio completamente administrado de control de código fuente que aloja repositorios basados en Git Seguro.
• AWS Lambda: es un servicio informático sin servidor que le permite ejecutar código sin aprovisionar ni administrar servidores, crear una lógica de escalado de clústeres basada en la carga de trabajo, mantener integraciones de eventos o administrar tiempos de ejecución.
• AWS Step Functions: es un servicio de flujos de trabajo visual y que requiere poco código que los desarrolladores usan para crear aplicaciones distribuidas, automatizar procesos de TI y empresariales y crear canalizaciones de datos y machine learning mediante servicios de AWS.
• AWS Systems Manager: es el centro de operaciones de AWS. Systems Manager proporciona una interfaz de usuario unificada para que pueda hacer un seguimiento y resolver problemas operativos en todas sus aplicaciones y recursos de AWS desde un solo lugar.
• AWS CloudFormation : ofrece una forma sencilla de modelar un conjunto de recursos relacionados de AWS y de terceros, aprovisionarlos de manera rápida y consistente y administrarlos a lo largo de sus ciclos de vida tratando la infraestructura como un código.
• AWS Cloud Development Kit (CDK): es un Framework de software para definir la infraestructura de la nube en el código y aprovisionarla a través de AWS CloudFormation.
• AWS SSO: administra de manera centralizada el acceso con inicio de sesión único (SSO) a varias aplicaciones empresariales y cuentas de AWS.
• AWS Network Firewall es un servicio administrado que facilita la implementación de protecciones de red esenciales para todas las cargas de trabajo alojadas en Amazon Virtual Private Clouds (VPC).

Para este escenario usaremos una estructura del código ligeramente diferente, vamos a separar por capas nuestros recursos, (network, stateful, stateless, front, backend, ides), también construiremos nuestros propios constructores para empaquetar funcionalidades como la personalización del ambiente, modificación de permisos y el redimensionamiento del disco. Es importante que en la práctica evitemos encapsular servicios stateful en constructores como las bases de datos.

Para la correcta ejecución de los recursos personalizados vamos a usar AWS Step Functions para controlar el flujo de una manera simple, comenzando por el redimensionamiento del disco y luego la ejecución de los comandos para agregar funcionalidades. Las Figura 1 y 2 muestra la máquina de estados construida, esta máquina de estados es invocada por un recurso personalizado de Cloudformation, en nuestro demo esta función solo ejecuta la invocación y en batch se ejecuta el proceso. A modo de demostración esta máquina de estado no tiene manejo de errores, es algo que te invitamos a profundizar y que en próximas publicaciones podremos abordar en detalle.

1. Cuando se crean los entornos para este escenario, por defecto se les asigna un rol que es compartido para los demás entornos, con la política básica para permitir la gestión de las sesiones usando sessions manager. En este paso se asigna un nuevo rol a la instancia con los demás permisos necesarios para interactuar con los servicios de AWS.
2. Ejecutamos el resize del disco, este proceso puede tardar dependiendo del tamaño del disco y en él se incluye el reinicio de la instancia EC2, por lo que agregamos un tiempo de 5 minutos de espera.
3. Finalmente se envían las instrucciones de configuración del ambiente a través de run command de AWS Systems Manager.

Figura 1. Descripción orquestación con AWS Step Functions

Figura 2. Máquina de estados desde vista desde consola de AWS Step Functions

La Figura 3 muestra el diagrama de arquitectura de referencia para este escenario. Podemos observar que el ingreso al entorno será a través de SSO, uso de IAM para los roles personalizados y la integración con CodeCommit que nos permite clonar sin necesidad de pasos adicionales nuestros repositorios dentro del entorno, la segmentación de red, el uso de AWS Network Firewall y VPC Endpoints para conectarse de manera privada a AWS Systems manager y así poder aplicar más controles alineados con el principio de mínima exposición y seguridad en profundidad. Con el fin de garantizar la trazabilidad y auditoria de las sesiones configuramos las preferencias de Session Manager para enviar los logs crifrados a un Bucket de S3 y a cloudwatch lo que nos permitrá análisis posteriores y automatización para responder a algún evento o comportamiento indeseado de nuestros usuarios sobre los entornos.

En nuestro codigo no hemos incluido el Stack de Network en próximos blogs profundizaremos sobre este servicio.

Figura 3. Diagrama de arquitectura

Reutilizaremos las funciones del post anterior con unas pequeñas modificaciones.
El código lo puedes descargar del repositorio
La Figura 4 muestra la estructura del codigo de proyecto

Figura 4. Estructura Código

El repositorio está compuesto por una carpeta donde se encuentran el codigo principal del proyecto cdk_secure_id_es_cloud9_aws que anida:
customs: en ella están las funciones lambda y el constructor que crea la maquina de estado y el recurso personalizado de Cloudformation.
ides: contiene la parametrización del ambiente cloud9.
network: contiene los recursos de VPC de acuerdo con el diagrama mostrado en la Figura 3.
project_configurations: contiene el script de shell para instalar los componentes adicionales, las configuraciones de despliegue del ambiente y un archivo para helper para convertir el script a lista y poder pasarlo a los constructores en la definición de los recursos, convertir el archivo environment_options.yaml a json.

Parámetros de entrada

El archivo environment_options.yaml contiene las definiciones de la cuenta destino, las propiedades para el ambiente de cloud9, los parámetros de red, así como los parámetros para las etiquetas y repositorios de codecommit dentro de la misma cuenta que se van usar por defecto en el ambiente. El nombre de ambiente debe coincidir con el tag Stack.

Ejemplo:

En este ejemplo estamos usando 16 GB de disco, un tamaño de instancia t3.small, un tiempo de apagado automático del ambiente en unidades de minutos (30) y usaremos también el repositorio SImpleApp.

Ejemplo archivo bootstrap.sh

Despliegue

En primer lugar, debemos copiar el archivo environment_options_example.yaml a environment_options.yaml y complementar con los parámetros de nuestra cuenta y recursos de red, a continuación, configurar el perfil de CLI para desplegar los servicios, al estar usando SSO nos apoyaremos en la utilidad aws-sso-util .

1. Configuracion CLI-
aws configure sso –profile profilename

2. Use Configuracion uitlidad SSO:

aws-sso-util configure profile shdplprd -u https://mydomain.awsapps.com/start#/\
Ahora desplegamos el entorno proyecto de cdk, es importante realizar el bootstrap para uso de cdk en nuestra cuenta si este es el primer despliegue sobre esa cuenta.
3. cdk deploy –profile profilename

En este paso podemos usar la bandera –require-approval para evitar la aprobación manual para el despliegue.

Ahora, veamos algunas evidencias en consola.

Figura 5. Consola CloudFormation

En la Figura 5 se nos encontramos tres stacks, uno para la red y dos para los ides ya que al usar esta modalidad se despliega un stack anidado adicional.

Figura 6. Consola Cloud9

La Figura 6 muestra el entorno en la consola de Cloud9, podemos verificar las opciones de red y capacidades computacionales.

Figura 7. Consola EC2

Ahora en la Figura 7 podemos notar el grupo de seguridad para la instancia de EC2 no posee reglas para permitir la conexión SSH y tenemos todo el tráfico de salida habilitado. De acuerdo con la Figura 3, el trafico de salida se puede controlar si agregamos un módulo para AWS Network Firewall.
La Figura 6 muestra el entorno en la consola de Cloud9, podemos verificar las opciones de red y capacidades computacionales.

Figura 8. Ejecución Step Functions

La Figura 8 muestra la ejecución del proceso de Steps Functions.
Finalmente vamos a validar nuestro entorno y a realizar un par de actividades adicionales

Figura 9. Consola Cloud9

En la Figura 9 vemos el entorno y la salida de ejecutar el comando terragrunt –version, una herramienta que abordaremos en otras entradas y que hemos preinstalado desde nuestro script de personalización del ambiente. También en la parde izquierda, en el explorador de archivos encontramos el contenido de nuestro repositorio.

Finalmente, validamos que el tiempo de apagado este alineado con los parámetros de entrada de nuestro proyecto y luego compartirlo con los demás usuarios que participen de nuestro proyecto.

Ahora el entorno esta listo para ser compartido con los demás integrantes del equipo.

Para limpiar el entorno ejecutamos.

cdk destroy –all –profile profilename

Consideraciones y conclusiones:

El tiempo de despliegue es aproximadamente de 10 minutos, esto debido a las tareas de aprovisionamiento de la instancia de EC2 administrada, los cambios de tamaño del disco y la ejecución de los recursos personalizados.

Agregar la capa de control y seguridad a nivel de redes garantiza la alineación con las políticas empresariales, y mitiga los riesgos respecto a la fuga de informacion y/o infección de los entornos de desarrollo por malware u otro tipo de amenazas.

El uso de session manager habilita las capacidades de auditoría y trazabilidad, así como la respuesta a incidentes de manera proactiva y automatizada.

Aplicar orquestación para las personalizaciones mitiga los errores y garantiza la correcta configuración de los ambientes, sin embargo, en este demo no hemos incluido control de errores en los procesos de Step Fuctions y se recomienda aplicarlos para un entorno productivo.

Usar los constructores de nivel 1 nos permite asignar configuraciones al ambiente que en el modelo anterior debían lanzarse desde el ambiente gráfico.
Compartir el ambiente también debe realizarse desde la consola web o en el constructor definir quién será su propietario, especificando un ARN asociado a la identidad que puede ser un usuario o un Rol.

Es importante tener en cuenta el time-out de run-command así como de las funciones lambda para evitar sobre costos o errores al momento de desplegar el stack.