Conectar una función Lambda a una base de datos protegida por Secrets Manager dentro de una VPC requiere configurar varios componentes que, por separado, parecen sencillos pero que en conjunto garantizan una arquitectura segura. Aquí se recorre paso a paso cómo crear un VPC endpoint, ajustar las security group rules, definir políticas IAM en Terraform y verificar la conexión con una petición real.
¿Por qué se necesita un VPC endpoint para acceder a Secrets Manager?
Cuando los recursos viven dentro de una VPC (Virtual Private Cloud), el tráfico está completamente aislado: no permite comunicación hacia afuera ni desde afuera por defecto [0:10]. Para que una Lambda pueda consultar credenciales almacenadas en Secrets Manager, AWS ofrece los endpoints o puntos de acceso, que crean un canal privado entre la VPC y el servicio sin salir a internet.
El proceso de creación en la consola es directo:
- Asignar un nombre descriptivo, por ejemplo
access-secrets-platzi [0:38].
- Seleccionar el tipo AWS services y buscar Secrets Manager.
- Asociar la VPC por defecto junto con todas las subnets en uso.
- Elegir IPv4 como tipo de dirección.
- Aplicar los security groups correspondientes y establecer la policy en full access [1:10].
Una vez creado, el endpoint queda ligado a la VPC donde residen las Lambdas y la base de datos.
¿Cómo ajustar las reglas del security group para permitir la conexión a RDS?
La base de datos PostgreSQL en RDS solo acepta conexiones desde la IP del desarrollador y el puerto de Postgres. Para que las Lambdas también puedan comunicarse, es necesario editar las inbound rules del security group por defecto [1:50].
Se agrega una regla nueva con estos valores:
- Tipo: all traffic, desde todos los puertos.
- Source: el default security group, que es el mismo donde se encuentran las Lambdas [2:16].
Con este cambio, cualquier recurso dentro de ese security group puede alcanzar la instancia de RDS.
¿Cómo definir la política IAM en Terraform para leer el secreto?
Dentro de la carpeta de infraestructura, en el directorio de IAM policies, se crea un archivo llamado can_get_db_password [2:50]. Este archivo declara un recurso aws_iam_policy cuyo contenido, codificado con jsonEncode, establece:
- Effect:
Allow.
- Action: operaciones sobre Secrets Manager.
- Resource: el ARN específico del secreto almacenado en la consola [3:24].
Es importante copiar el ARN real desde la consola de Secrets Manager, no confundirlo con el secret name [3:30].
¿Cómo vincular la política al rol de la Lambda?
Dentro del módulo de roles, se agrega una nueva entrada can_get_db_password que recibe el ARN de la política recién creada [4:00]. Luego, en el archivo main.tf, se pasa esa variable desde el módulo de policies hacia el módulo de roles con la referencia module.policies.can_get_db_password_arn.
El módulo de policies necesita un bloque output para exponer el valor del ARN, de modo que main pueda consumirlo [4:30].
¿Qué variables de entorno necesita la Lambda para conectarse a la base de datos?
Dentro de la configuración de la Lambda get_metrics se definen las siguientes variables [4:55]:
dbHost: el endpoint de la instancia RDS copiado desde la consola.dbPort: 5432, el puerto estándar de PostgreSQL.dbUser: platzi.dbPassword: el secret name (no el ARN) del secreto en Secrets Manager.dbName: postgres.
Con estas variables, el código en tiempo de ejecución sabe dónde conectarse y qué secreto solicitar.
¿Cómo compilar, desplegar y verificar la conexión?
El flujo de despliegue separa la compilación del binario del aprovisionamiento de infraestructura [5:30]. Primero se ejecuta make publish desde la carpeta de la Lambda para compilar y subir el binario a S3. Después, con terraform plan y terraform apply, se proveen los recursos y se enlazan las políticas al rol.
Para verificar, se obtiene un nuevo token desde el flujo de autenticación en el navegador [6:05], se copia el valor de access_token y se pega en Postman como bearer token. Al enviar la petición GET con el email del autor registrado, la respuesta retorna un HTTP 200 con el conteo de commits y su detalle [6:55].
Lo más relevante: las credenciales de la base de datos no existen en texto plano en ningún archivo de Terraform ni en la arquitectura. Viven exclusivamente en Secrets Manager y se consultan en tiempo de ejecución, lo que refuerza la seguridad de toda la solución [7:10].
