Hace unas semanas se anunció una feature muy solicitada por la comunidad  de serverless en AWS, para dar un poco de contexto el ecosistema de AWS, las lambdas tienen muchas formas de invocarse, la invocación que generalmente se expone de manera pública es la invocación por medio de peticiones HTTP, antes de este feature, esto funcionaba con un servicio llamado API Gateway, este  permite el aprovisionamiento de un endpoint, el cual invoca funciones lambdas, como se puede apreciar en la  Figura 1, sin embargo, este servicio puede llegar a ser un poco complejo de usar

Figura 1: Exposición de un endpoint por medio de una API Gateway

Api Gateway complejo?

Para usar estos servicios juntos se requería un poco de conocimiento y además de trabajo, esto  está bien porque  este servicio ofrece features como

  • Alto rendimiento
  • Facilidad de monitoreo
  • Herramientas de seguridad
  • Herramientas para flujos de autorización

todos estos son servicios que requieren un poco de conocimiento sobre los flujos de comunicación HTTP, sin embargo, en algunas ocasiones no es necesario todo este ecosistema completo, ya que se requiere algo más sencillo, como en el caso de los webhooks una tabla comparativa se puede ver a continuación

Figura 2: Tabla comparativa, obtenido de https://www.serverless.com/blog/aws-lambda-function-urls-with-serverless-framework

Webhooks

Los webhooks son usados por muchas empresas como slack, discord y facebook , esto se debe a sus grandes beneficios, básicamente el webhook es un  concepto de notificación sencilla cuando ocurren ciertos eventos y ciertas situaciones, una de sus particularidades en estos desarrollos, es que generalmente se hacen en dos etapas, y una de esas ocurre antes de salir al live, en esta situación es donde entra a tomar gran valor esté nuevo feature, ya que fácilmente se puede tener un servicio de escucha para probar diferentes tipos de notificaciones, la configuración en una lambda para activar la url, es bastante sencillo, veamos un ejemplo

Ejemplo con serverless

para realizar la configuración de una URL a una lambda, agregamos el siguiente código al archivo serverless.yml

functions:
  hello:
    handler: handler.hello
    url:
      cors: true
 
  world:
    handler: handler.world
    url:
      cors:
       allowedOrigins:
        - https://test1.com
        - https://test2.com
      allowedHeaders:
        - Content-Type
        - Authorization
      allowedMethods:
        - GET
      allowCredentials: true
      exposedResponseHeaders:
        - Special-Response-Header
      maxAge: 6000
serverlerss.yml

cuando se realice el  deploy, se obtiene la url generada, tal cual como si fuera con API Gateway, ahora a nivel gráfico es más sencillo, solo se dirigen a sus lambdas en config y seleccionan dónde dice Function URL new , se agregan los cors y al final se genera la url

Figura 3: Configuración gráfica para generar una URL en una lambda

¿Es Seguro?

Uno de los principales beneficios de tener una arquitectura desplegada en una misma nube, en este caso AWS, es que se soporta sobre las políticas como autorización, en general eso quiere decir que las lambdas cuando invocan a otras lambdas o servicios, no usan procesos de autenticación o autorización "tradicional", como se aprecia en la siguiente Figura 4

Figura 4: Funcionamiento de una arquitectura con lambdas usando IAM Policy

de esta manera se logra disminuir tiempos de procesamiento, esto trae consigo un concepto que se llama SCP(Service Control Policies) el cual, es un concepto que se enfoca en gestionar los permisos de las cuentas de la organización, este es un tema muy interesante porque es como se logra administrar la gobernanza de muchas cuentas de diferentes empleados y de esta forma lograr tener mayor seguridad y transparencia, entonces, porque esto es importante?, como mencione, este flujo viaja tranquilamente entre servicios y recursos haciendo dos preguntas principales quien me puede invocar?, y  quien puedo invocar?, existiendo diferentes modelos , por lo tanto, si una lambda se le permite que exponga un endpoint mediante una URL, esto puede ocasionar que el servicio quede público y que en consecuencia, ahora se tenga acceso al flujo dentro de la nube privada (VPC), lo que podría ocasionar un problema en temas de seguridad de la información, además seguramente haciendo ruido a alguna certificación que vela por la información personalde los usuarios, por eso una buena práctica sería limitar la asignación de este atributo, por lo menos en un ambiente productivo, este ser vería más o menos así

Figura 5: Configuración para limitar la generación de URLS en las lambdas, obtenido de https://www.linkedin.com/feed/update/urn:li:activity:6917848114129170432/

Conclusiones

Este feature será muy útil para desarrollos tempranos que se deben integran con notificaciones de uso por medio de webhooks, evitando así para pruebas el uso de proxies, sin embargo, para temas productivos hay que revisar con lupa su implementación, ya que esto podría acarrear problemas de seguridad de la información, una buena práctica en estos ambientes es que por medio de los Service Control Policies se deshabilite su uso o se limite  ciertos casos muy específicos