Este artículo explica un patrón práctico de seguridad en la nube para proteger secretos almacenados en AWS Secrets Manager cuando se trabaja con Terraform y no se puede modificar la política de identidad del rol asignado. El problema es habitual en entornos como AWS Academy Learner Labs, integraciones de tipo "trae tu propia cuenta" de plataformas SaaS o landing zones gestionados por un equipo central, donde el rol viene con permisos amplios y no se pueden crear políticas IAM nuevas.
La solución propuesta se apoya en el modelo de doble capa de autorización de AWS: además de la política basada en identidad, se puede asociar una política basada en recurso directamente al secreto. AWS evalúa ambas, y un Deny explícito en cualquiera de las dos bloquea la petición. Si ninguna deniega, basta con que una conceda el acceso. Así, una política de recurso bien acotada puede restringir lo que una política de identidad demasiado abierta permitiría por defecto.
El artículo recorre la implementación paso a paso con Terraform: comprobaciones previas (identidad asumida y disponibilidad de Secrets Manager), definición del provider y de variables sensibles como la contraseña de base de datos, resolución dinámica del ARN del rol heredado, creación del secreto y de su política de recurso, escritura segura del valor y verificación del acceso con pruebas positivas y negativas. También se mencionan requisitos de versiones (Terraform 1.5 o superior, provider de AWS 5.0 o superior) y la variante write-only disponible a partir de Terraform 1.11.
Queda fuera del alcance la rotación automática de secretos mediante funciones Lambda, que el autor anuncia como tema de una próxima entrega.