Debe usar el almacén de parámetros de SSM sobre las variables de entorno de Lambda

AWS Lambda introdujo soporte nativo para variables de entorno (con soporte de cifrado KMS). Sin embargo, el uso de variables de entorno de AWS Lambda dificulta compartir valores de configuración entre funciones e implementar un acceso detallado a datos confidenciales (p. ej., credenciales, claves de API, etc.)

actualizado : esta publicación se actualizó el 15/09/2017 luego del lanzamiento de Serverless framework 1.22.0 que introdujo soporte para el almacenamiento de parámetros SSM listo para usar. Vaya al final de la publicación para ver cómo se compara con otros enfoques.

AWS Lambda anunció la compatibilidad nativa con las variables de entorno a fines de 2016. Pero incluso antes de eso, el marco Serverless había admitido variables de entorno y las estaba usando felizmente cuando mi equipo y yo migramos nuestro backend monolítico de Node.js a serverless .

Sin embargo, a medida que nuestra arquitectura se expandió, encontramos varios inconvenientes con la administración de configuraciones con variables de entorno.

Difícil de compartir configuraciones entre proyectos

El mayor problema para nosotros fue la incapacidad de compartir configuraciones entre proyectos, ya que las variables de entorno son funciones específicas en tiempo de ejecución.

El marco sin servidor tiene la noción de servicios , que es solo una forma de agrupar funciones relacionadas. Puede especificar variables de entorno de todo el servicio, así como funciones específicas.

Un ejemplo de serverless.yml que especifica tanto variables de entorno de todo el servicio como específicas de la función.

Sin embargo, a menudo descubrimos que las configuraciones deben compartirse entre varios servicios. Cuando estas configuraciones cambian, tuvimos que actualizar y volver a implementar todas las funciones que dependen de ellas , lo que en sí mismo se estaba convirtiendo en un desafío para rastrear estas dependencias en muchos repositorios de Github que son mantenidos por diferentes miembros del equipo.

Por ejemplo, como estábamos migrando de un sistema monolítico pieza por pieza mientras ofrecíamos nuevas funciones, no pudimos alejarnos de la base de datos monolítica MongoDB de una sola vez. Significaba que muchas funciones compartían cadenas de conexión MongoDB. Cuando una de estas cadenas de conexión cambió, y lo hizo varias veces, siguió el dolor y el sufrimiento.

Otro valor configurable que solemos compartir es la URL raíz de los servicios intermedios. Al ser una red social, muchas de nuestras operaciones iniciadas por el usuario dependen de los datos de relación, por lo que muchos de nuestros microservicios dependen de la API de relación. En lugar de codificar la URL para la API de relaciones en cada servicio (uno de los antipatrones de microservicio mortales), debe almacenarse en un servicio de configuración central.

Control de acceso detallado difícil de implementar

Cuando necesite configurar datos confidenciales como credenciales, claves de API o cadenas de conexión de base de datos, la regla general es:

1. los datos deben cifrarse en reposo (incluye no verificarlos en el control de fuente en texto sin formato)
2. los datos deben cifrarse en tránsito
3. aplicar el principio de privilegio mínimo al acceso de funciones y personal a los datos

Si está operando en un entorno fuertemente regulado, entonces el punto 3 podría ser más que una buena práctica, sino un requisito normativo. Sé de muchas empresas fintech y gigantes financieros donde el acceso a las credenciales de producción está estrictamente controlado y disponible solo para un puñado de personas en la empresa.

Si bien esfuerzos como el complemento serverless-secrets cumplen con el punto 1, combina la capacidad de uno para implementar funciones de Lambda con el acceso de uno a datos confidenciales, es decir. quien implementa la función también debe tener acceso a los datos confidenciales. Esto podría estar bien para muchas nuevas empresas, ya que todos tienen acceso a todo, idealmente su proceso para administrar el acceso a los datos puede evolucionar con las necesidades de la empresa a medida que crece.

Almacén de parámetros de SSM

Mi equipo superó las variables de entorno y comencé a buscar otras soluciones populares en este espacio: etcd, consul, etc. Pero realmente no me gustaban estas soluciones porque:

• son costosos de ejecutar: necesita ejecutar varias instancias EC2 en una configuración multi-AZ para HA
• tienes que administrar estos servidores
• cada uno tiene una curva de aprendizaje con respecto tanto a la configuración del servicio como a las herramientas CLI
• necesitábamos una fracción de las características que ofrecen

Esto fue 5 meses antes de que Amazon anunciara SSM Parameter Store en re:invent 2016, por lo que en ese momento construimos nuestra propia API de configuración con API Gateway y Lambda.

Hoy en día, solo debe usar SSM Parameter Store porque:

• es un servicio completamente administrado
• compartir configuraciones es fácil, ya que es un servicio centralizado
• se integra con KMS listo para usar
• ofrece un control detallado a través de IAM
• registra un historial de cambios
• puede usarlo a través de la consola, AWS CLI , así como a través de su API HTTPS

En resumen, cumple todos nuestros requisitos.

Puede crear cadenas seguras cifradas por KMS.

Puede ver un historial de todos los cambios en estos parámetros.

Tiene un control detallado sobre los parámetros a los que puede acceder una función.

Hay un par de límites de servicio a tener en cuenta:

• máximo 10,000 parámetros por cuenta
• la longitud máxima del valor del parámetro es de 4096 caracteres
• max 100 valores pasados para un parámetro

biblioteca cliente

Tener un lugar centralizado para almacenar parámetros es solo una cara de la moneda. Aún debe esforzarse en crear una biblioteca de cliente robusta que sea fácil de usar y admita:

• almacenamiento en caché y caducidad de caché
• configuraciones de intercambio en caliente cuando el valor de configuración de origen ha cambiado

Aquí hay una de esas bibliotecas de clientes que preparé para una demostración:

Para usarlo, puede crear objetos de configuración con la función loadConfigs . Estos objetos expondrán propiedades que devuelven los valores de configuración como Promise (de ahí el yield , que es el poder mágico que obtenemos con co ).

También puede tener diferentes valores de configuración con diferentes vencimientos de caché.

Si desea experimentar con el almacenamiento de parámetros de SSM de Lambda (o ver este cliente de caché en acción), consulte este repositorio e impleméntelo en su entorno de AWS. No he incluido ningún evento HTTP, por lo que tendría que invocar las funciones desde la consola.

Actualización 15/09/2017: la versión 1.22.0 del marco Serverless que introdujo la compatibilidad con los parámetros de SSM listos para usar.

Con esta última versión del marco Serverless, puede especificar el valor de las variables de entorno para que provengan directamente del almacén de parámetros de SSM.

En comparación con muchos de los enfoques existentes, tiene algunos beneficios:

• evite verificar datos confidenciales en texto sin formato en el control de fuente
• evite duplicar los mismos valores de configuración en múltiples servicios

Sin embargo, todavía se queda corto en muchos frentes (según mis propios requisitos):

• dado que obtiene los valores de los parámetros de SSM en el momento de la implementación, aún combina su capacidad para implementar su función con acceso a datos de configuración confidenciales
• los valores de configuración se almacenan en texto sin formato como variables de entorno de Lambda , lo que significa que no necesita los permisos de KMS para acceder a ellos, puede verlos en la consola de Lambda a simple vista
• Además de lo anterior, si la función se ve comprometida por un atacante (que luego tendría acceso a process.env ), entonces podrá encontrar fácilmente los valores descifrados durante la sonda inicial (vaya a la marca 13:05 en este video donde di una demostración de lo fácil que se puede hacer esto)
• debido a que los valores se hornean en el momento de la implementación, no le permite propagar fácilmente los cambios en los valores de configuración . Para realizar un cambio de valor de configuración, deberá a) identificar todas las funciones dependientes ; y b) volver a implementar todas estas funciones

Por supuesto, su requerimiento puede ser muy diferente al mío, y ciertamente creo que es una mejora con respecto a muchos de los enfoques que he visto. Pero, personalmente, sigo pensando que deberías:

1. obtener valores de parámetros de SSM en tiempo de ejecución
2. almacenar en caché estos valores e intercambiar en caliente cuando cambien los valores de origen

Hola, mi nombre es Yan Cui . Soy un héroe sin servidor de AWS y el autor de Production-Ready Serverless . He ejecutado cargas de trabajo de producción a escala en AWS durante casi 10 años y he sido arquitecto o ingeniero principal en una variedad de industrias que van desde la banca, el comercio electrónico, la transmisión de deportes hasta los juegos móviles. Actualmente trabajo como consultor independiente enfocado en AWS y serverless.

Puede ponerse en contacto conmigo a través de correo electrónico , Twitter y LinkedIn .

Consulte mi nuevo curso,Guía completa de AWS Step Functions .

En este curso, cubriremos todo lo que necesita saber para usar el servicio de AWS Step Functions de manera efectiva. Incluye conceptos básicos, disparadores de eventos y HTTP, actividades, patrones de diseño y mejores prácticas.

Consigue tu copia aquí .

Venga a conocer las MEJORES PRÁCTICAS operativas para AWS Lambda: CI/CD, funciones de prueba y depuración localmente, registro, monitoreo, seguimiento distribuido, implementaciones canary, administración de configuración, autenticación y autorización, VPC, seguridad, manejo de errores y más.

También puedes obtener un 40% de descuento sobre el precio nominal con el código ytcui .

Consigue tu copia aquí .