{"id":12394,"date":"2021-10-14T07:48:46","date_gmt":"2021-10-14T07:48:46","guid":{"rendered":"https:\/\/beta.bluetab.net\/serverless-microservices\/"},"modified":"2023-10-17T12:55:45","modified_gmt":"2023-10-17T12:55:45","slug":"serverless-microservices","status":"publish","type":"post","link":"https:\/\/bluetab.org\/en\/serverless-microservices\/","title":{"rendered":"Serverless Microservices"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Serverless Microservices<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\"\"<\/a><\/figure>

Francisco Linaje<\/a><\/h4>

AWS Solutions Architect<\/p><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t

\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/i>\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/i>\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

En esta\u00a0pr\u00e1ctica cloud<\/strong>\u00a0veremos como construir microservicios dentro de AWS siguiendo el paradigma serverless. Este tipo de soluci\u00f3n permite disponer de sistemas completamente administrados por AWS donde nosotros no deberemos preocuparnos por disponibilizar los recursos o administrarlos, simplemente especificaremos dentro de su configuraci\u00f3n las pol\u00edticas de ejecucion y escalado si se necesitasen, el pago por tanto es exclusivamente por uso.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Requisitos<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Para poder realizar esta pr\u00e1ctica deberemos disponer de las siguientes instalaciones que nos permitir\u00e1n poder desarrollar los microservicios y operar el entorno.<\/p>

  • Terraform: Desde donde crearemos y desplegaremos nuestro backend e infra.<\/li>
  • Un usuario con credenciales de acceso al cli de AWS (access_key y secret_key) y permisos necesarios para operar los servicios empleados en la pr\u00e1ctica.<\/li>
  • AWS cli v2: Permitir\u00e1 configurar los credenciales con aws configure, opcionalmente se pueden realizar exports del access_key y secret_key.<\/li>
  • Un IDE en este caso visual-studio-code<\/li>
  • Conocimiento b\u00e1sico en Api Rest y AWS<\/li>
  • Postman<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Overview<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Se plantea un escenario donde diferentes usuarios mediante aplicaciones multiplataforma acceden a diferentes recursos dentro de la app consumiendo una API Rest segura desplegada en AWS, para ello deber\u00e1n en primer lugar autenticarse contra el pool de cognito para obtener un token JWT que les permitir\u00e1 consumir los diferentes endpoints de la API.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Autenticaci\u00f3n y Autorizaci\u00f3n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Para poder ofrecer seguridad a la API y que sus servicios solo sean consumidos por usuarios autorizados, debemos emplear un broker que nos pueda ofrecer autenticacion y a su vez autorizacion sobre estos servicios.<\/p>

    En primer lugar deberemos de entender el flujo que sigue un usuario para poder ser autenticado y autorizado para consumir un microservicio. En el siguiente diagrama se pueden ver como en una serie de pasos un usuario puede consumir el endpoint.<\/p>

    1. El usuario se autentica mediante sus credenciales contra el broker.<\/li>
    2. Si los credenciales son correctos, el broker generara un token JWT que servir\u00eda como mecanismo de autorizaci\u00f3n al poder validar que el usuario es quien dice ser.<\/li>
    3. Este token deber\u00e1 emplearse en todas las llamadas a la API Rest, para ello se enviar\u00e1 en el header de Authorization junto a un prefijo Bearer.<\/li>
    4. Si el token es validado por el broker, se le otorgar\u00e1 acceso al consumo del microservicio.<\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      \u00bfQue es JWT o Json Web Token?<\/strong><\/h3>

      Json Web Token es un est\u00e1ndar abierto (RFC 7519) donde se define una forma aut\u00f3noma de asegurar integridad en los datos enviados gracias a que va firmada digitalmente con HMAC (firma simetrica – misma clave) o RSA(firma asimetrica – par de claves privada\/publica) y asi asegurar que el peticionario es una entidad segura. Adem\u00e1s estos tokens pueden estar encriptados adicionalmente para ocultar los reclamos a terceros. El escenario principal donde se emplea es en la autorizaci\u00f3n del peticionario.<\/p>

      Cada token JWT consta de tres partes separados por un \u201c.\u201d de la forma header.payload.signed codificados en base64 por separado.<\/p>

      Header<\/strong>: Indica el tipo de token y su firma, en el caso de RS256 incluir\u00e1 el kid que identifica la clave p\u00fablica del emisor del Token que se empleara para verificar la firma. Mediante el iss del payload y el kid de la clave podremos ver en el navegador https:\/\/\/.well-known\/jwks.json la firma publica empleada para descifrar el token.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      Payload<\/strong>: Contiene los claims que permiten verificar los atributos de la generaci\u00f3n del token: iss (emisor), aud (audience), exp( expiracion) y otros campos que se puedan a\u00f1adir adicionalmente para enviar informaci\u00f3n.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      AWS Cognito<\/strong><\/h3>

      Cognito es un servicio completamente administrado que ofrece autenticaci\u00f3n de usuarios para aplicaciones multiplataforma, adem\u00e1s permite el empleo de identidades federadas como Google, Amazon, Facebook, etc para su registro.<\/p>

      Los usuarios podr\u00e1n registrarse y loguearse contra un pool de usuarios que funciona como directorio de usuarios donde ser\u00e1n albergados los par\u00e1metros de autenticaci\u00f3n: email, password, n\u00famero de tel\u00e9fono, etc. Se ofrecen adem\u00e1s opciones de confirmaci\u00f3n de usuario mediante c\u00f3digo o enlace v\u00eda email o sms. Los usuarios autenticados recibir\u00e1n un token de acceso que podr\u00e1n emplear para recibir autorizaci\u00f3n a los microservicios de Api Gateway. Mediante otras opciones no planteadas en este caso de uso, se podr\u00e1 recibir credenciales temporales STS de AWS para acceder directamente a servicios AWS mediante la funci\u00f3n AssumeRoleWithWebIdentity mediante los pool de identidades.<\/p>

      Los usuarios emplearan la interfaz web de Cognito para autenticarse y recibir un c\u00f3digo que podr\u00e1n intercambiar por un token JWT que emplear\u00e1n como autorizaci\u00f3n en los microservicios desplegados en Api Gateway.<\/p>

      Empezaremos creando nuestro pool de usuarios.<\/p>

      • Asignaremos un nombre al pool.<\/li>
      • A\u00f1adiremos el atributo de acceso y verificaci\u00f3n, en este caso email.<\/li>
      • Definiremos como se realiza la verificaci\u00f3n: via enlace. Adem\u00e1s si se har\u00e1 por defecto via SNS \u201cCOGNITO_DEFAULT\u201d o via SES \u201cDEVELOPER\u201d.<\/li>
      • La recuperaci\u00f3n de la cuenta se har\u00e1 v\u00eda el email verificado, siendo la prioridad 1, como maxima prioridad en caso de a\u00f1adir futuros m\u00e9todos opcionales.<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t
        resource "aws_cognito_user_pool" "user_pool" {\n        name = var.cognito.user_pool_name\n        auto_verified_attributes = ["email"]\n        username_attributes = ["email"]\n\n        verification_message_template {\n            email_subject_by_link = "APP Notification - Account Verification"\n            email_message_by_link = "Please click the link to verify your email address: {##VERIFY EMAIL##}\\n<br><br>\\n"\n            default_email_option = "CONFIRM_WITH_LINK"\n        }\n\n        email_configuration {\n                email_sending_account = "COGNITO_DEFAULT"\n        }\n\n        account_recovery_setting {\n            recovery_mechanism {\n            name = "verified_email"\n            priority =  1\n            }\n        }\n    } <\/code><\/pre>