Terminamos 04-02 con la base de datos mercadofresco-pedidos cifrada con AES-256 y una clave de KMS con política, rotación y separación de funciones. Y aun así, cualquiera que se siente delante del portátil de Luis puede conectarse a esa base de datos, porque la contraseña del usuario mfadmin está escrita en texto plano en al menos cinco sitios:

1. En el user data de la plantilla de lanzamiento lt-mercadofresco-tienda, que se puede leer desde el servicio de metadatos de cualquier instancia de la tienda.
2. En /etc/mercadofresco/tienda.conf dentro de cada instancia.
3. En un fichero .env que Luis se pasó a sí mismo por chat cuando montó el entorno de desarrollo.
4. En el historial de comandos de la sesión en la que la usó por primera vez.
5. En la cabeza de Marta, que la eligió hace catorce meses y no ha cambiado desde entonces.

El cifrado no ayuda aquí. Como vimos en la primera tabla de 04-02, el cifrado en reposo protege del disco robado y del snapshot compartido por error, pero no protege de unas credenciales válidas en manos equivocadas. Esta lección resuelve exactamente ese problema.

AWS ofrece dos servicios para custodiar valores de configuración y credenciales: AWS Systems Manager Parameter Store y AWS Secrets Manager. No son competidores, son complementarios, y la mitad de esta lección consiste en saber cuál usar para qué.

Advertencia. Los ejemplos son didácticos y las credenciales, ficticias. Toda gestión real de credenciales, rotación y cumplimiento (RGPD, PCI DSS) debe ser revisada por un profesional de seguridad antes de aplicarse a un entorno con datos de clientes. Un secreto mal migrado —especialmente una rotación mal configurada— deja la aplicación fuera de servicio y sin forma evidente de volver atrás. Nunca uses credenciales reales en un entorno de pruebas.

1. Por qué las credenciales en el código son un problema estructural
2. Qué pasa exactamente cuando un secreto llega a Git
3. Configuración y secreto no son lo mismo
4. Parameter Store: tipos de parámetro
5. Jerarquía por rutas, versiones y niveles
6. La configuración de MercadoFresco en Parameter Store
7. Secrets Manager: secretos, versiones y etapas
8. Cifrado con KMS y políticas de recurso
9. Rotación automática: el ciclo de cuatro pasos
10. Configurar la rotación de mercadofresco/produccion/rds/mfadmin
11. Usuario único frente a alternancia de dos usuarios
12. Tabla comparativa y la recomendación para MercadoFresco
13. Consumo desde la aplicación: boto3 y caché
14. Consumo desde Lambda, EC2, ECS y CloudFormation
15. Permisos mínimos para leer un secreto
16. La migración: sacar la contraseña del user data
17. Qué no hay que guardar aquí
18. Auditoría del acceso a secretos
19. Detección de secretos filtrados en el repositorio
20. Coste, cuotas y limpieza

No es descuido, es un problema de diseño. Una credencial escrita en un fichero de configuración tiene cuatro propiedades que la condenan:

La cuarta es la que perpetúa el problema. Marta sabe que la contraseña debería cambiarse, pero cambiarla significa editar la plantilla de lanzamiento, reiniciar todas las instancias del ASG, avisar a Luis y cruzar los dedos. Como el riesgo de la operación parece mayor que el de no hacer nada, no se hace nunca. La rotación automática rompe ese círculo, y por eso es el corazón de esta lección.

Conviene ser concreto, porque el error más caro es creer que basta con borrarlo en el commit siguiente:

Esto no elimina nada. El fichero sigue en el historial, accesible con git show <commit-anterior>:.env. Y si el repositorio estuvo en un servidor compartido o alguien hizo un clone, esas copias también lo tienen. El único procedimiento correcto es:

1. Rotar la credencial inmediatamente. Considérala comprometida desde el momento en que se escribió. Este paso es obligatorio y no es opcional.
2. Reescribir el historial (git filter-repo, BFG) y forzar el push. Esto rompe los clones de todo el equipo, así que hay que coordinarlo.
3. Buscar en los registros si la credencial se usó desde algún sitio inesperado.
4. Añadir un escáner que impida que vuelva a pasar.

El orden importa: rotar primero. Reescribir el historial mientras la credencial sigue siendo válida es tratar el síntoma. Si el repositorio es público, los bots que rastrean GitHub encuentran credenciales de AWS en cuestión de minutos, y el coste de una cuenta usada para minar criptomonedas se cuenta en miles de dólares por día.

Esta distinción decide qué servicio usar:

Casos frontera que conviene resolver de antemano:

• El nombre de usuario de la base de datos (mfadmin) es configuración. La contraseña es secreto. Pero se guardan juntos, porque la rotación cambia ambos en el caso de alternancia.
• El punto de enlace de RDS es configuración: no es secreto y ya es público en tu VPC.
• Una clave de API de un proveedor de pagos es un secreto, aunque sea de un entorno de pruebas.
• El identificador de la distribución de CloudFront (E2QWERTY123ABC) es configuración.

Parameter Store es un componente de AWS Systems Manager. Guarda pares clave-valor con tres tipos:

Notas sobre SecureString:

• Si no indicas --key-id, se usa la clave gestionada por AWS alias/aws/ssm, que es gratuita pero no controlable. Para valores que importan, usa tu clave.
• Para leer el valor descifrado hace falta --with-decryption y permiso kms:Decrypt sobre la clave. Es la misma doble autorización de SSE-KMS.

La jerarquía por rutas es la característica que hace útil a Parameter Store. Los nombres se estructuran como rutas y se pueden leer en bloque:

Con una sola llamada la aplicación carga toda su configuración:

Y la jerarquía se convierte directamente en control de acceso: una política que concede ssm:GetParametersByPath sobre /mercadofresco/produccion/* deja fuera todo el entorno de desarrollo sin enumerar un solo parámetro.

Versiones. Cada put-parameter --overwrite crea una versión nueva y conserva las anteriores. Se puede leer una versión concreta con nombre:numero, y etiquetar una versión con un alias:

Volver atrás tras un cambio desafortunado es cambiar la etiqueta estable a la versión anterior. No hay despliegue de por medio.

Niveles.

MercadoFresco cabe de sobra en el nivel estándar: cero euros por toda su configuración. El nivel avanzado se justifica cuando necesitas más de 4 KB —un certificado, por ejemplo— o las políticas de caducidad, que avisan cuando un parámetro lleva demasiado tiempo sin cambiar.

Hay además un modo de rendimiento alto (--parameter-tier, con ssm:GetParameters a 3.000 peticiones por segundo) que se factura aparte; solo hace falta si la aplicación lee parámetros en el camino crítico de cada petición, cosa que no debería hacer: para eso está la caché.

Fíjate en que el usuario mfadmin está aquí y la contraseña no. El nombre de usuario es configuración; la contraseña va al otro servicio. Y observa el efecto colateral: el user data de lt-mercadofresco-tienda, que hasta ahora era una lista de valores incrustados, pasa a ser una llamada genérica idéntica en todos los entornos.

Un secreto de Secrets Manager es un valor —normalmente un JSON— cifrado con KMS, con versiones y un mecanismo de rotación. La pieza que hay que entender bien son las etapas de versión.

Cada versión de un secreto lleva una o varias etiquetas de etapa:

Estas tres etiquetas son el mecanismo que hace que la rotación no corte el servicio. Durante unos segundos coexisten la contraseña vieja (AWSCURRENT) y la nueva (AWSPENDING), y solo cuando la nueva se ha probado se intercambian las etiquetas. Ninguna aplicación se queda sin credencial válida en ningún momento.

Crear el secreto de MercadoFresco:

La estructura del JSON no es arbitraria: esos nombres de campo (engine, host, port, dbname, username, password) son exactamente los que espera la función de rotación gestionada de AWS para PostgreSQL. Si los cambias, la rotación no funcionará. Es uno de los detalles que más tiempo hace perder.

--kms-key-id alias/mercadofresco-datos conecta esta lección con la anterior: el secreto se cifra con la clave que construimos en 04-02, y por tanto queda sujeto a su política. Quien no pueda usar la clave no podrá leer el secreto aunque tenga secretsmanager:GetSecretValue. Otra vez la doble autorización.

Como bucket, cola o clave, un secreto admite política de recurso. Sirve para dos cosas: acceso entre cuentas y refuerzo con Deny.

Es un Deny con StringNotEquals: «deniega la lectura a todo el que no sea uno de estos tres». Recuerda de 04-01 que un Deny gana siempre, así que ni una política de identidad con secretsmanager:* sobre * puede saltárselo. Es la forma más robusta de blindar el secreto más sensible de la cuenta, y hay que incluir en la lista el rol de rotación o la rotación fallará.

--block-public-policy rechaza la política si concediera acceso público. Úsalo siempre.

Aquí está el valor diferencial de Secrets Manager. La rotación la ejecuta una función Lambda, que AWS proporciona ya escrita para los motores de base de datos habituales, y que se invoca cuatro veces con un paso distinto cada vez.

Los cuatro pasos, con lo que importa de cada uno:

La consecuencia práctica más importante es la que casi nadie anticipa: entre setSecret y finishSecret hay una ventana en la que la base de datos ya tiene la contraseña nueva pero AWSCURRENT todavía devuelve la vieja. Si tu aplicación cachea el secreto durante una hora y abre una conexión nueva justo en esa ventana, recibirá un error de autenticación.

Por eso el patrón correcto en la aplicación es:

1. Cachear el secreto (una lectura por petición es carísima y lenta).
2. Al recibir un error de autenticación, invalidar la caché y reintentar una vez.

Ese reintento de una línea es lo que convierte la rotación en algo transparente. Sin él, cada rotación produce un puñado de errores en los registros.

La forma más sencilla es dejar que Secrets Manager cree la Lambda desde su plantilla gestionada:

Los parámetros de --rotation-rules:

• AutomaticallyAfterDays: 30: cada 30 días.
• ScheduleExpression: cuándo exactamente. Aquí, los martes a las 3 de la madrugada. Es deliberado: nunca un jueves ni un viernes, por el pico de pedidos.
• Duration: "2h": ventana de dos horas dentro de la cual puede empezar.

La Lambda de rotación necesita tres cosas que se olvidan constantemente:

1. Acceso de red a la base de datos. Debe estar en la VPC vpc-mercadofresco, en las subredes snet-mercadofresco-app-a/-b, y sg-mercadofresco-basedatos debe aceptar el 5432 desde su grupo de seguridad. Aquí se aplica lo que vimos en 03-02: referenciar el SG de origen en lugar de un CIDR.
2. Acceso a la API de Secrets Manager. Como está en subredes privadas y su salida a internet pasa por nat-mercadofresco-a, o bien se acepta ese coste o bien se crea un endpoint de VPC de interfaz para secretsmanager, del mismo modo que hicimos con vpce-mercadofresco-s3 en 03-01. Sin una de las dos cosas, la Lambda se queda colgada hasta agotar el tiempo de espera y el síntoma no dice nada.
3. Permisos. Su rol necesita secretsmanager:GetSecretValue, PutSecretValue, UpdateSecretVersionStage, DescribeSecret, GetRandomPassword, más kms:Decrypt y kms:GenerateDataKey sobre alias/mercadofresco-datos.

Rotación manual inmediata, muy útil para probar antes de confiar en el calendario:

Prueba la rotación en desarrollo antes de activarla en producción. Es el consejo más importante de esta lección: una rotación mal configurada deja la tienda sin base de datos, y el error de setSecret a medias puede requerir cambiar la contraseña a mano para recuperarse.

Existen dos estrategias de rotación, y la elección tiene consecuencias reales de disponibilidad:

MercadoFresco empieza con usuario único porque es más simple y la tienda implementa el reintento. Cuando el volumen crezca —o cuando entren en juego contenedores que arrancan y mueren constantemente, en el módulo 10— la alternancia de dos usuarios será la opción sensata. La plantilla gestionada de AWS existe para ambos casos: SecretsManagerRDSPostgreSQLRotationSingleUser y ...RotationMultiUser.

La recomendación para MercadoFresco, escrita como norma del equipo:

Todo lo que sea una credencial capaz de dar acceso a datos de clientes va a Secrets Manager, con rotación activada. Todo lo demás va a Parameter Store.

Aplicado:

Coste de esta división: 2 secretos × 0,40 = 0,80 USD al mes, más unos céntimos de llamadas. Toda la configuración, gratis. Si lo hubiéramos metido todo en Secrets Manager, los 25 valores costarían 10 USD mensuales; si lo hubiéramos metido todo en Parameter Store, no tendríamos rotación. La división no es purismo, es economía.

Un detalle práctico muy cómodo: Parameter Store puede leer secretos de Secrets Manager usando el prefijo /aws/reference/secretsmanager/. Así la aplicación usa una sola API para todo:

La versión ingenua —leer el secreto en cada petición— tiene tres problemas: latencia de decenas de milisegundos, coste por llamada y riesgo de superar la cuota de peticiones. La correcta usa caché con invalidación ante error de autenticación:

El bucle for intento in (1, 2) es toda la lógica que hace falta: primer intento con la caché, segundo con recarga forzada, y solo se reintenta si el error es de autenticación. Un error de red o de tiempo de espera se propaga tal cual, porque recargar el secreto no lo arreglaría.

Para producción existe la biblioteca oficial, que añade caducidad por tiempo y es más completa:

Con secret_refresh_interval=3600 se hacen 24 llamadas al día por instancia en lugar de una por petición: de decenas de miles a dos docenas.

Lambda: la extensión de parámetros y secretos. AWS publica una capa que arranca un pequeño servidor HTTP local dentro del entorno de ejecución y cachea por ti. Se añade la capa, se configura con variables de entorno y se consulta por localhost:

La extensión mantiene la caché entre invocaciones que reutilizan el mismo entorno de ejecución —recuerda el modelo de arranques en frío y en caliente de 02-05—, así que en la práctica una función muy invocada hace una llamada cada cinco minutos en lugar de una por invocación.

EC2. Con el rol rol-mercadofresco-tienda asignado, boto3 encuentra las credenciales solo. No hay nada que configurar salvo los permisos.

ECS. Las definiciones de tarea permiten inyectar secretos directamente como variables de entorno, sin que el código llame a la API. Se verá en 10-01.

CloudFormation: referencias dinámicas. Se puede referenciar un secreto sin escribirlo en la plantilla:

La sintaxis {{resolve:secretsmanager:<secreto>:SecretString:<campo>}} se resuelve en el momento del despliegue y el valor nunca aparece en la plantilla ni en los eventos de la pila. Se desarrolla en 09-01.

Esta es la política que se adjunta a rol-mercadofresco-tienda:

Tres detalles que importan:

• Los seis interrogantes finales del ARN. Secrets Manager añade un sufijo aleatorio de 6 caracteres al ARN de cada secreto (...mfadmin-AbCdEf). Si escribes el ARN sin sufijo, la política no coincide con nada. -?????? usa el comodín de un carácter para cubrirlo. Es el error número uno con Secrets Manager y su síntoma —AccessDenied con una política aparentemente correcta— desconcierta a cualquiera. La alternativa es terminar en -*, algo más laxa.
• kms:ViaService limitado a secretsmanager. La tienda puede descifrar a través de Secrets Manager y de S3 (por la declaración de 04-02), pero no puede llamar a kms:Decrypt directamente contra cualquier blob que consiga.
• ssm:GetParametersByPath acotado a /mercadofresco/produccion/*. La tienda de producción no ve la configuración de desarrollo, y viceversa.

Y lo que no hay: secretsmanager:ListSecrets, que revelaría los nombres de todos los secretos de la cuenta, ni acceso a ningún otro secreto. La tienda lee exactamente uno. Si mañana se añade el secreto de la pasarela de pago, hará falta una decisión explícita para concederlo.

Estado inicial del user data de lt-mercadofresco-tienda, tal como quedó en 02-01:

El plan de migración, en orden y sin cortar el servicio:

El paso 1 es crucial y contraintuitivo: se guarda la contraseña actual, sin cambiarla. Así los pasos 1 a 7 no alteran nada funcionalmente y se pueden revertir en cualquier momento. La contraseña solo cambia en el paso 8, cuando todo lo demás ya está probado.

Nuevo user data, sin una sola credencial:

La contraseña no se escribe en ningún fichero: el user data deja el nombre del secreto, y la aplicación lo lee en memoria al arrancar y cuando lo necesita. El user data, que es visible desde los metadatos de la instancia, ya no contiene nada aprovechable.

Despliegue con renovación progresiva, como en 02-01:

Y por fin el paso 10, la limpieza, que es la parte que se olvida:

• Borrar /etc/mercadofresco/tienda.conf de las instancias antiguas (que se destruyen solas con la renovación).
• Borrar el .env de los portátiles y reescribir el historial de Git si llegó a subirse.
• Purgar el historial de comandos de las sesiones donde se usó.
• Y, sobre todo, rotar: la contraseña anterior debe considerarse comprometida.

Ni Secrets Manager ni Parameter Store son un almacén de propósito general:

Un caso que merece mención: para RDS existen además las credenciales gestionadas (--manage-master-user-password), donde RDS crea y rota el secreto automáticamente sin que configures nada. Es lo más sencillo si la base de datos es nueva; MercadoFresco no lo usa porque mercadofresco-pedidos ya existía, pero para una instancia nueva es la primera opción a considerar.

Cada llamada a GetSecretValue queda registrada en CloudTrail (05-03), con quién, cuándo, desde qué IP y con qué resultado. Es la propiedad que ningún fichero .env puede ofrecer:

Lo que Marta vigila:

• Lecturas desde principales inesperados —cualquiera que no sea rol-mercadofresco-tienda o el rol de rotación.
• Lecturas fuera de horario o desde IP desconocidas.
• Un pico de lecturas, que sugiere que alguien está enumerando secretos.
• DeleteSecret o PutResourcePolicy, que deberían ser rarísimos.

En 05-01 convertiremos esto en una alarma real de CloudWatch que avise al tema alertas-mercadofresco; por ahora basta con saber que el rastro existe.

Prevenir es más barato que rotar. Dos capas:

En el portátil, antes del commit. git-secrets instala un hook que rechaza commits con patrones de credenciales:

--scan-history revisa todo el historial, no solo el estado actual. Ejecutarlo la primera vez en un repositorio con años de vida suele dar sorpresas.

En el pipeline. El escaneo local se puede saltar; el del pipeline no. Herramientas como gitleaks, trufflehog o el escaneo de secretos de la plataforma se ejecutan en cada git push y detienen la construcción. Lo integraremos en la fase de compilación en 08-02, junto con las pruebas y el análisis estático.

Y una regla de higiene que vale más que cualquier herramienta:

Cálculo para MercadoFresco:

Menos de un dólar al mes por eliminar el riesgo más común y más caro de una infraestructura. Compáralo con el coste de una brecha notificable bajo el RGPD y la discusión se cierra sola.

Limpieza. Un secreto no se borra de inmediato: hay un periodo de recuperación de entre 7 y 30 días, por la misma razón que en KMS.

Cuidado con la asimetría: los parámetros se borran al instante y no se recuperan. Antes de borrar en bloque una ruta de Parameter Store, exporta una copia.

Olvidar el sufijo de seis caracteres en el ARN del secreto. Es el error más frecuente con Secrets Manager. El ARN real es ...secret:mercadofresco/produccion/rds/mfadmin-AbCdEf, y una política que termine en mfadmin sin más no coincide con nada. Usa -?????? o -*.

Cachear el secreto sin invalidar la caché ante un error de autenticación. Cada rotación produce entonces una tanda de errores. El reintento único es cuatro líneas de código y lo resuelve.

Poner la Lambda de rotación fuera de la VPC. No podrá conectarse a mercadofresco-pedidos y la rotación fallará en setSecret, que es el peor momento posible. Debe estar en las subredes de aplicación y sg-mercadofresco-basedatos debe aceptar su grupo de seguridad.

Olvidar la salida a la API de Secrets Manager desde la subred privada. La Lambda se queda colgada hasta agotar el tiempo de espera y el mensaje de error no dice nada útil. Necesita NAT o un endpoint de interfaz.

Cambiar los nombres de los campos del JSON del secreto. La función de rotación gestionada espera engine, host, port, dbname, username, password. Si los renombras «para que se lean mejor», la rotación no funciona.

Activar la rotación en producción sin haberla probado. Pruébala primero en una copia de la base de datos, y con --rotate-immediately para no esperar 30 días a descubrir que algo falla.

Guardar todo en Secrets Manager porque es «el sitio seguro». 25 valores son 10 USD al mes en lugar de 0,80. La configuración no sensible va a Parameter Store.

Programar la rotación un jueves por la noche. El pico de MercadoFresco es el viernes. Rota los martes de madrugada, cuando hay dos días laborables por delante para reaccionar.

Consejo: usa una convención de nombres desde el primer día. <proyecto>/<entorno>/<servicio>/<recurso> permite escribir políticas por prefijo y ver de un vistazo a qué entorno pertenece cada cosa.

Consejo: guarda el punto de enlace dentro del secreto además de en Parameter Store. Es lo que espera la rotación gestionada, y evita que la aplicación tenga que combinar dos fuentes para abrir una conexión.

Consejo: pon una alarma sobre NextRotationDate. Una rotación que lleva 45 días sin ejecutarse en un secreto configurado a 30 es una rotación rota que nadie ha visto.

Consejo: audita cada trimestre quién puede leer cada secreto. El acceso crece solo, y list-secrets con las políticas de recurso da la foto en un minuto.

MercadoFresco integra una pasarela de pago y un proveedor de mensajería. Aparecen estos ocho valores:

1. Clave de API de producción de la pasarela de pago (rota cada 90 días por política del proveedor).
2. URL base de la API de la pasarela: https://api.pasarela.example/v2.
3. Identificador de comercio: MF-2026-ES-0042.
4. Secreto de firma de los webhooks entrantes de la pasarela.
5. Tiempo máximo de espera de la pasarela: 8 segundos.
6. Usuario y contraseña del SFTP del proveedor de mensajería.
7. Lista de códigos postales con reparto en 24 h.
8. Contraseña de una segunda base de datos de informes, de solo lectura.

Decide para cada uno el servicio, el tipo y el nombre completo, siguiendo la convención de MercadoFresco, y justifica los tres casos que consideres más discutibles. Calcula el coste mensual resultante.

Marta activa la rotación de mercadofresco/produccion/rds/mfadmin. La rotación se ejecuta y falla. En los registros de la Lambda aparece:

Y en Secrets Manager, describe-secret muestra una versión con etapa AWSPENDING que lleva ahí tres horas, mientras AWSCURRENT sigue apuntando a la versión antigua.

Responde: (a) ¿en qué paso del ciclo ha fallado y qué significa exactamente ese mensaje?; (b) enumera en orden las cuatro causas más probables y cómo comprobar cada una; (c) ¿está la aplicación caída en este momento y por qué?; (d) ¿qué hay que limpiar antes de reintentar?

Escribe la política de permisos completa del rol rol-rotacion-mfadmin, que asume la Lambda de rotación. Debe poder: leer y escribir el secreto mercadofresco/produccion/rds/mfadmin (y solo ese), mover etapas de versión, generar contraseñas aleatorias, usar alias/mercadofresco-datos a través de Secrets Manager, escribir sus propios registros y funcionar dentro de vpc-mercadofresco.

Solución 1

Casos discutibles:

• El identificador de comercio (3). Parece sensible porque identifica a la empresa ante el proveedor, pero por sí solo no autoriza nada: sin la clave de API no sirve de nada, y aparece en las facturas. Es configuración. Si el proveedor lo tratara como credencial, cambiaría la decisión.
• El secreto de firma de webhooks (4). Podría parecer configuración porque no «abre» nada: solo se usa para verificar firmas entrantes. Pero quien lo conozca puede falsificar notificaciones de pago confirmado, es decir, conseguir pedidos gratis. Es un secreto de primer orden.
• Los códigos postales (7). No es secreto en absoluto —está publicado en la web— pero es configuración que cambia a menudo y conviene tenerla fuera del código para poder ampliar la cobertura sin desplegar. StringList con get-parameter y --query 'Parameter.Value' devuelve la cadena separada por comas.

Coste: 4 secretos nuevos × 0,40 = 1,60 USD/mes, más los 2 anteriores = 2,40 USD/mes en Secrets Manager. Parameter Store: 4 parámetros más, 0 USD. Si se hubieran metido los ocho valores en Secrets Manager: 3,20 USD solo por estos ocho, cuatro veces más, sin ninguna ventaja para los cuatro que no rotan.

Solución 2

(a) Ha fallado en el paso setSecret, el segundo del ciclo. El mensaje concreto —«unable to connect with previous secret»— dice que la Lambda ha intentado conectarse a la base de datos usando la credencial actual (AWSCURRENT) para poder ejecutar el ALTER USER, y no ha podido. Es decir: el problema no es la contraseña nueva, es que la Lambda no consigue autenticarse con la vieja.

(b) Cuatro causas, en orden de probabilidad:

1. Red. La Lambda no está en vpc-mercadofresco, o está en las subredes equivocadas, o sg-mercadofresco-basedatos no acepta el 5432 desde su grupo de seguridad. Comprobación: aws lambda get-function-configuration --query 'VpcConfig' y revisar las reglas de entrada del SG de la base de datos con describe-security-groups.
2. La contraseña de AWSCURRENT no es la real. Si al crear el secreto se puso una contraseña inventada en lugar de la que realmente tiene mfadmin, la Lambda no puede autenticarse. Comprobación: intentar conectarse manualmente con psql usando el valor de AWSCURRENT desde un bastión.
3. Los campos del JSON no son los esperados. Si falta dbname, port o engine, o si están escritos de otra forma, la Lambda construye mal la cadena de conexión. Comprobación: leer el secreto y comparar campo a campo con el formato esperado.
4. El punto de enlace es incorrecto —por ejemplo, quedó el antiguo tras la migración a la instancia cifrada de 04-02, que cambió el DNS. Comprobación: aws rds describe-db-instances --query 'DBInstances[].Endpoint.Address' y comparar.

(c) No, la aplicación no está caída. Y esa es exactamente la virtud del diseño de etapas: AWSCURRENT sigue apuntando a la versión antigua, que es la que sigue funcionando en la base de datos, y es la que devuelve get-secret-value. La rotación fallida es un problema operativo urgente, pero no un incidente de servicio. Si hubiera fallado después de setSecret —con la contraseña ya cambiada en la base de datos pero AWSCURRENT sin promocionar— entonces sí habría corte.

(d) Antes de reintentar hay que eliminar la versión colgada en AWSPENDING, o Secrets Manager intentará continuar la rotación a medias en lugar de empezar de cero:

Después, corregir la causa, probar en desarrollo y reintentar con --rotate-immediately.

Solución 3

Justificación de cada bloque:

• El secreto, uno solo, con el sufijo -?????? y la condición secretsmanager:resource/AllowRotationLambdaArn, que asegura que este rol solo puede operar sobre secretos cuya rotación está asignada precisamente a esta Lambda. Es una defensa extra frente a que alguien reutilice el rol.
• GetRandomPassword no admite ARN de recurso; por eso "Resource": "*". No es peligroso: genera cadenas aleatorias y no da acceso a nada.
• KMS acotado con kms:ViaService a Secrets Manager: el rol no puede descifrar objetos de S3 con la misma clave.
• Los registros del propio grupo de la función, con el :* final.
• Las tres acciones de ec2: son obligatorias para cualquier Lambda dentro de una VPC: crea y destruye una interfaz de red elástica en cada arranque en frío. No admiten ARN concreto porque la interfaz aún no existe cuando se comprueba el permiso. Es una de las poquísimas veces en que "Resource": "*" es inevitable, y se puede acotar con condiciones sobre ec2:Subnet y ec2:SecurityGroup si se quiere apurar.

No aparece secretsmanager:ListSecrets, que revelaría el inventario de secretos de la cuenta, ni ninguna acción de RDS: la Lambda cambia la contraseña conectándose por SQL, no por la API de AWS.

La contraseña de mfadmin ya no está donde no debía. Ha salido del user data de lt-mercadofresco-tienda, del fichero de configuración de las instancias, del .env de Luis y del historial de comandos, y vive en mercadofresco/produccion/rds/mfadmin, un secreto cifrado con alias/mercadofresco-datos, protegido por una política de recurso que deniega su lectura a todo principal que no sea rol-mercadofresco-tienda, marta o el rol de rotación, y que rota sola cada 30 días, los martes de madrugada, sin que nadie tenga que acordarse ni asumir el riesgo de hacerlo a mano.

Entiendes por qué la rotación no corta el servicio: el mecanismo de etapas de versión —AWSCURRENT, AWSPENDING, AWSPREVIOUS— y el ciclo de cuatro pasos createSecret → setSecret → testSecret → finishSecret, donde la contraseña nueva se crea, se aplica y se prueba antes de promocionarse, y donde un fallo en testSecret aborta todo dejando la vieja intacta. Sabes también dónde está la ventana peligrosa —entre setSecret y finishSecret— y por qué la aplicación debe invalidar la caché y reintentar una vez ante un error de autenticación: cuatro líneas que convierten la rotación en algo invisible.

Distingues configuración de secreto, y con ello cuál de los dos servicios usar. La configuración de MercadoFresco vive en Parameter Store bajo /mercadofresco/produccion/..., con jerarquía por rutas que permite cargarla entera con una llamada y escribir permisos por prefijo, con versiones y etiquetas para volver atrás sin desplegar, y gratis en el nivel estándar. Los secretos viven en Secrets Manager, a 0,40 USD cada uno. El total de la lección es 0,82 USD al mes, y sabes argumentar por qué meterlo todo en el servicio caro habría costado diez veces más sin aportar nada.

En lo práctico sabes leer un secreto desde boto3 con caché e invalidación, desde Lambda con la extensión de parámetros y secretos que cachea entre invocaciones, desde EC2 con el rol y sin configurar nada, y desde CloudFormation con referencias dinámicas {{resolve:secretsmanager:...}} que nunca escriben el valor en la plantilla (09-01); en ECS se inyectan en la definición de tarea y lo veremos en 10-01. Conoces los permisos mínimos para leer un secreto —incluido el sufijo de seis caracteres del ARN, el error que más tiempo hace perder— y sabes que el rastro de cada lectura queda en CloudTrail (05-03) y que el escaneo de secretos filtrados se automatiza en el pipeline (08-02).

MercadoFresco tiene ya la casa en orden hacia dentro: identidades mínimas, datos cifrados y credenciales rotadas. Pero todo eso protege de amenazas que pasan por la puerta de la API. Queda la otra mitad del problema, la que llega por la puerta de delante y no necesita ninguna credencial. Recuerda la regla DENY numerada 50 con la que en 03-02 bloqueamos aquella IP que hacía miles de peticiones por minuto: funcionó porque era una dirección. Si mañana llegan peticiones desde diez mil direcciones distintas repartidas por todo el mundo, esa regla no sirve de nada, la NACL tiene un límite duro de entradas, y el grupo de Auto Scaling reaccionará como está diseñado para reaccionar —arrancando instancias— convirtiendo el ataque en una factura. En la lección 04-04, «AWS Shield», veremos qué es realmente un ataque de denegación de servicio distribuida, en qué se diferencian los ataques volumétricos de los de capa de aplicación, qué protección tienes ya activada y gratis en CloudFront, Route 53 y el ALB, qué añade Shield Advanced por 3.000 USD al mes —y si eso tiene sentido para una empresa del tamaño de MercadoFresco—, y cómo se distingue en caliente un ataque de un pico legítimo de un viernes por la tarde.