Proteger los recursos de una API es fundamental en cualquier arquitectura serverless. Cuando trabajas con API Gateway y Serverless Framework, puedes configurar llaves de acceso (API Keys) con apenas unas líneas de código, eliminando casi por completo la intervención manual. A continuación se explica paso a paso cómo definir un endpoint como privado, generar un API Key de forma automatizada y validar su funcionamiento.
¿Qué es un API Key y por qué usarlo en API Gateway?
Un API Key es una llave alfanumérica que API Gateway valida automáticamente en cada petición entrante [0:10]. Si la llave es correcta, el usuario obtiene acceso al recurso; si no, recibe un error de autorización. Este mecanismo forma parte de las estrategias de seguridad disponibles en API Gateway y resulta útil para controlar el consumo de endpoints sin necesidad de implementar sistemas de autenticación más complejos.
El concepto de endpoint privado significa que API Gateway verificará la presencia y validez de un API Key antes de permitir el acceso. Sin esa llave, cualquier solicitud será rechazada con un código 403 Forbidden [4:35].
¿Cómo se define un endpoint privado en Serverless Framework?
La configuración es directa y se realiza en el archivo serverless.yml. Para marcar una función como privada, basta con agregar la propiedad private: true dentro del evento HTTP correspondiente [1:05].
- En el evento HTTP del Get Users, se añade la llave
private con valor true.
- Esto le indica a API Gateway que debe exigir un API Key en cada petición.
Para que funcione, también es necesario declarar el API Key en la sección de provider [1:30]:
- Dentro de
provider, se agrega la llave apiGateway.
- Bajo
apiGateway, se define apiKeys con una lista de nombres.
- El nombre puede seguir una convención como el nombre del servicio seguido de "-api-key" [1:55].
Con estas dos modificaciones el proyecto queda listo para desplegarse con la protección activada.
¿Se puede desplegar de forma automática con CI/CD?
Sí. Dado que el proyecto ya cuenta con un flujo de CI/CD mediante GitHub Actions, solo es necesario hacer un commit y un push [2:10]. El flujo de automatización detecta los cambios, ejecuta las etapas de testing, construye la layer y finalmente despliega con CloudFormation.
Durante el despliegue, CloudFormation actualiza los recursos asociados: las Lambda Layers, las funciones y los eventos vinculados a API Gateway [3:15]. Todo ocurre sin intervención manual, aunque también es posible ejecutar sls deploy directamente desde la terminal.
¿Cómo se crearía un API Key de forma manual en la consola de AWS?
Desde la consola de API Gateway, al seleccionar la API correspondiente, existe una sección llamada API Keys [2:55]. Allí se pueden crear llaves indicando:
- El nombre del API Key.
- Si el valor será personalizado o autogenerado.
- Una descripción opcional.
Este proceso manual equivale exactamente a lo que Serverless Framework automatiza con la configuración en el archivo YAML.
¿Cómo validar que el API Key funciona correctamente?
Una vez completado el despliegue, la salida de consola muestra un nuevo apartado: además de los endpoints, funciones y layers, ahora aparece el API Key generado [4:15].
Para probarlo en Postman:
- Sin el API Key, al enviar la petición se obtiene un 403 Forbidden, confirmando que el recurso está protegido [4:35].
- Para autenticarse, se agrega un header llamado
x-api-key con el valor de la llave obtenida del despliegue [4:50].
- Es importante habilitar el header con el checkbox en Postman; de lo contrario, no se envía [5:25].
- Al ejecutar la petición con el header habilitado, se recibe un 200 OK y la información solicitada [5:35].
Un detalle práctico: si el despliegue acaba de finalizar, la Lambda puede tardar unos segundos en estar disponible en todas las regiones, lo que se conoce como tiempo de propagación.
Finalmente, se puede verificar en la consola de AWS que el API Key aparece registrado en la sección correspondiente de API Gateway [5:45]. Con esto queda integrada la protección por API Key al proyecto serverless. El siguiente paso natural es explorar los Custom Authorizers, que permiten implementar lógica de autorización más avanzada.
¿Qué opinas de este método de autenticación? ¿Lo consideras suficiente para tus proyectos o preferirías combinarlo con otras estrategias? Comparte tu experiencia en los comentarios.
