unit-testing amazon-web-services amazon-cloudformation

unit testing - ¿Hay alguna manera de probar la plantilla de AWS Cloudformation por unidad?



unit-testing amazon-web-services (3)

Cuando decimos que la formación de nubes es ''Infraestructura como código'', la siguiente pregunta que surge inmediatamente es cómo se puede probar este código. ¿Podemos hacer algún tipo de prueba unitaria básica de este código?

Y estoy descontando la validación de la formación de la nube porque esa es solo una forma de realizar la validación sintáctica, y eso puedo hacerlo con cualquier otro validador JSON / YAML gratuito.

Estoy más inclinado a algún tipo de validación funcional, posiblemente probando que he definido todas las variables que se utilizan como referencias. Posiblemente se compruebe que las propiedades que estoy utilizando son compatibles con ese componente

No se espera que pruebe si los permisos son correctos o si no he agotado mis límites. Pero al menos algo más allá de la validación de sintaxis JSON / YAML básica


Esta herramienta "cfn-nag" analiza una colección de plantillas de CloudFormation y aplica reglas para encontrar patrones de código que podrían llevar a una infraestructura insegura. Los resultados de la herramienta incluyen los identificadores de recursos lógicos para violar recursos y una explicación de qué regla se ha violado. Lectura adicional: https://stelligent.com/2016/04/07/finding-security-problems-early-in-the-development-process-of-a-cloudformation-template-with-cfn-nag/

Si bien hay bastantes reglas particulares que la herramienta intentará hacer coincidir, las categorías generales son:

Políticas de recursos e IAM (S3 Bucket, SQS, etc.) Hace coincidir las políticas que son excesivamente permisivas de alguna manera (por ejemplo, comodines en acciones o principales)

Reglas de ingreso y egreso del grupo de seguridad Coincide con reglas que son demasiado liberales (por ejemplo, una regla de ingreso abierta a 0.0.0.0/0, el rango de puertos 1-65535 está abierto)

Registros de acceso Busca los registros de acceso que no están habilitados para los recursos aplicables (por ejemplo, Elastic Load Balancers y CloudFront Distributions)

Cifrado (lado del servidor) cifrado que no está habilitado o no se aplica para los recursos aplicables (p. Ej., Volúmenes EBS o para llamadas PutObject en un grupo S3)


Las pruebas que describió (al menos más allá del análisis JSON) se pueden realizar parcialmente analizando las plantillas de CloudFormation mediante bibliotecas programáticas que se utilizan para generar / leer plantillas. No prueban la plantilla explícitamente, pero pueden generar una excepción o error en las condiciones en las que se usa una propiedad que no está definida para un recurso.

Echa un vistazo a go-cloudformation: https://github.com/crewjam/go-cloudformation

Aparte de eso, necesitas ejecutar la pila para ver los errores. Creo que probar IaaC es uno de los principales desafíos en la automatización de infraestructura. No solo pruebas unitarias, sino también pruebas de integración y validación continua.


Aquí hay un desglose de cómo se pueden aplicar varios métodos de prueba de software a las plantillas / pilas de CloudFormation:

Linting

Para linting (verificando el código de la plantilla de CloudFormation para la corrección de sintaxis / gramática), puede usar la API ValidateTemplate para verificar la estructura básica de la plantilla, y la API CreateChangeSet para verificar sus propiedades de recursos con más detalle.

  • Tenga en cuenta que ValidateTemplate realiza una verificación mucho más exhaustiva que un simple comprobador de sintaxis JSON / YAML: valida la anatomía correcta de la plantilla , la sintaxis y el uso correctos de las funciones intrínsecas y la resolución correcta de todos los valores de Ref .
  • ValidateTemplate comprueba la sintaxis básica de CloudFormation, pero no verifica los recursos de su plantilla contra esquemas de propiedad específicos. Para verificar la estructura de los Parámetros, Recursos y Propiedades de su plantilla con los tipos de Recursos de AWS, CreateChangeSet debería devolver un error si alguno de los parámetros o propiedades del recurso no están bien formados.

Examen de la unidad

Realizar la prueba de la unidad primero requiere una respuesta a la pregunta: ¿cuál es la unidad de funcionalidad independiente más pequeña que se puede / debe probar? Para CloudFormation, creo que la unidad comprobable más pequeña es el Resource .

Los tipos de recursos oficiales de AWS son compatibles / mantenidos por AWS (y son implementaciones propietarias de todos modos), por lo que no requieren pruebas de unidades adicionales escritas por los desarrolladores usuarios finales.

Sin embargo, sus propios recursos personalizados pueden y deben ser probados por unidades. Esto se puede hacer usando un marco de prueba adecuado en el propio lenguaje de la implementación (por ejemplo, para los recursos personalizados respaldados por Lambda, tal vez una biblioteca como lambda-tester sería un buen punto de partida).

Pruebas de integración

Este es el tipo de prueba más importante y relevante para las pilas de CloudFormation (que en su mayoría sirven para unir varios recursos en una aplicación integrada), y también el tipo que podría usar más refinamiento y desarrollo de mejores prácticas. Aquí hay algunas ideas iniciales sobre cómo realizar una prueba de integración del código de CloudFormation al crear / actualizar pilas completas que contienen recursos reales de AWS:

  • Con un lenguaje de scripting, realice una creación de pila de CloudFormation con el AWS SDK del idioma. Diseñe la plantilla para devolver las Outputs pila que reflejen el comportamiento que desea probar. Una vez que el lenguaje de scripting crea la pila, compare los resultados de la pila con los valores esperados (y luego, opcionalmente, elimine la pila posteriormente en un proceso de limpieza).
  • Use los recursos de AWS::CloudFormation::WaitCondition para representar pruebas / aserciones exitosas, de modo que una creación de pila exitosa indique una ejecución de prueba de integración exitosa, y una creación de pila fallida indica una ejecución de prueba de integración fallida.

Más allá de CloudFormation, una herramienta interesante que vale la pena mencionar en el espacio de prueba de infraestructura como código es kitchen-terraform , un conjunto de complementos para Test Kitchen que le permite escribir conjuntos de pruebas de integración completamente automatizados para los módulos Terraform . Un arnés de prueba de integración similar podría eventualmente ser construido para CloudFormation, pero aún no existe.