Conexión segura de Lambdas a Secrets con VPC

Configura conexiones seguras en AWS con pasos claros: Lambdas en una VPC aislada, acceso privado a Secrets Manager, reglas de security groups para RDS y permisos con Terraform. Aprenderás a evitar credenciales planas, usar endpoints de VPC, adjuntar una IAM Policy al role de la lambda y validar el flujo con Postman.

¿Cómo habilitar acceso a Secrets Manager en una VPC privada?

Una VPC aislada bloquea tráfico entrante y saliente. Para que las lambdas puedan leer secretos, se crea un endpoint de VPC para Secrets Manager. Esto permite acceso privado sin salir a internet y mantiene la arquitectura segura.

¿Qué es un endpoint de VPC para Secrets Manager?

• Recurso que conecta la VPC con servicios de AWS de forma privada.
• Tipo: servicio de AWS para Secrets Manager.
• Selección: VPC por defecto y todas las subnets usadas.
• Dirección: IPv4.
• Security group: aplicar los dos grupos de seguridad indicados.
• Policy: full access en el endpoint para simplificar el alcance del servicio.
• Resultado: los recursos de la VPC pueden consultar secretos sin NAT ni internet.

¿Qué security groups necesita RDS para permitir lambdas?

• Verifica en RDS la instancia en uso y sus security group rules.
• La regla de entrada mostraba acceso solo desde Postgres y una IP propia.
• Se añade una regla nueva: all traffic, todos los puertos, source tipo custom con el security group default donde están las lambdas.
• Importante: no usar el database security group equivocado, debe ser el default de las lambdas.
• Guardar cambios y confirmar que las lambdas pueden llegar a la base de datos.

¿Cómo dar permisos con IAM y Terraform para leer el secret?

Los permisos se modelan como policies de IAM que el role de la lambda asume. Con Terraform se define la policy, se referencia el ARN del secreto y se adjunta al role correcto para limitar el alcance.

¿Cómo crear la policy can get db password?

• Archivo en infraestructura/IAM/policies: nombre sugerido can get db password.
• Recurso: AWS IAM Policy con nombre can get db password.
• Contenido: jsonencode con efecto Allow hacia Secrets Manager.
• Dato clave: copiar el ARN real del secreto desde Secrets Manager y reemplazar el ARN de ejemplo.
• Consejo: el policy generator ayuda a estructurar el documento JSON.

¿Cómo adjuntar la policy al role de la lambda?

• Identifica el role de la lambda, por ejemplo Repo Collector.
• Declara una variable para el ARN de la policy: can get db password arn.
• Adjunta la policy al role con el nombre claro can get db password.
• Recuerda pasar la referencia desde main usando el module de policies.

¿Cómo exponer el output del módulo de policies?

• En el módulo de policies, define un output que exponga can get db password arn.
• En main, consume ese output y así enlazas la policy con el role.
• Sin este output, el role no recibe la policy correcta.

¿Cómo configurar la lambda y validar el flujo end-to-end?

Con el permiso listo, toca definir variables de entorno, compilar y desplegar. Finalmente, se prueba con Postman usando un access token y se verifica el 200 con el contenido esperado.

¿Qué variables de entorno usar para Postgres?

• Función: get metrics.
• dbHost: usar el endpoint de RDS copiado desde la consola.
• Puerto: 5432 porque es Postgres.
• Usuario: platzi.
• dbPassword: usar el secret name, no el secret arn.
• db name: postgres.
• Ventaja: las credenciales no quedan en texto plano ni en archivos de Terraform.

¿Cómo compilar y desplegar con make y Terraform?

• Desde la lambda de get metrics, ejecutar make publish.
• El binario se sube a S3; Terraform solo aprovisiona y referencia ese artefacto.
• En infraestructura: terraform plan para ver cambios (políticas y su unión al role).
• Aplicar con terraform apply y confirmar con yes.
• Nota: el despliegue no compila código, solo gestiona recursos y enlaza el binario de S3.

¿Cómo probar en Postman y qué respuesta esperar?

• Obtener nueva URL de token y abrirla en Google Chrome u otro navegador.
• Ingresar credenciales del usuario registrado y copiar el access token.
• En Postman, en la petición de get commit, pegar el token sin espacios.
• Consultar en la base el correo del usuario sample y usarlo como parámetro author.
• Enviar la petición y validar el 200 con campos: author (email enviado), count (número de commits), y arreglo commits con id, project y message.
• Confirmación final: conexión a base de datos operativa y secreto leído de forma segura.

Si te quedó alguna duda o quieres compartir tu implementación con Terraform y Lambdas, cuéntalo en los comentarios y sigamos afinando permisos, security groups y pruebas en Postman.