Seguridad

Cómo los stacks manejan secretos (noEcho), scopes de privilegio, aislamiento multi-tenant y auditoría.

El módulo de stacks toca las piezas más sensibles del tenant: credenciales de proveedores, secretos de negocio, agentes y hooks. Estas son sus garantías y lo que te toca a ti.

Secretos: nunca en el template

Un template es código: se versiona, se comparte, se pega en chats. Por eso ningún valor sensible puede escribirse en él — el validador rechaza literales en los campos de credencial (apiKey de una cuenta, value de un secreto). El flujo correcto:

Declara un parámetro con noEcho: true.
Referéncialo con !Ref desde el campo write-only.
Pasa el valor real en parameters al crear el stack o proponer el changeset.

A partir de ahí, el valor solo existe en memoria durante el despliegue. En todo lo demás — el stack persistido, los changesets, la traza de eventos, las respuestas de la API, la UI — aparece como ***noEcho***. Durante la ventana entre proponer y ejecutar, el valor se guarda cifrado y se purga al cerrar el changeset. Los cambios de valor se detectan por huella criptográfica, nunca comparando el plaintext, y un output que intente exponer un parámetro noEcho es un error de validación.

Aun así, trata el template con cuidado

El template no lleva secretos, pero sí describe tu arquitectura (agentes, prompts, tools, endpoints internos). Compártelo con el mismo criterio que el resto de tu código.

Scopes: deploy es administrar el tenant

Los tres scopes (iac:read, iac:manage, iac:deploy) están pensados para separar responsabilidades: quien revisa no necesita poder ejecutar. Ten presente que iac:deploy equivale a administrar el tenant completo — un changeset puede crear cuentas con credenciales, reescribir prompts de agentes y registrar hooks que llaman URLs externas.

Recomendaciones:

Para CI, emite una API key dedicada con iac:deploy, rótala periódicamente y revócala ante cualquier sospecha.
Para agentes de IA que operan stacks, dales iac:manage por defecto y reserva iac:deploy para flujos con aprobación humana del changeset.
No mezcles iac:deploy en keys de uso general del producto.

Aislamiento multi-tenant

Todo stack, changeset y recurso vive en un tenant; los ids de otros tenants no existen para ti: referenciar un id físico ajeno falla la validación con "no existe o no es visible".
Los recursos de plataforma (compartidos) son de solo lectura desde stacks.
Las API keys de tenant fijan el tenant por sí mismas; el campo tenantId del body se ignora para ellas.

Robustez del parser

Los templates se parsean en modo seguro: sin tags YAML personalizados más allá de !Ref / !GetAtt / !Sub, sin merge keys, con alias limitados y límites duros de tamaño (512 KB, 200 recursos, 20 000 nodos). Un template hostil o malformado se rechaza antes de tocar cualquier gestor.

Auditoría

La traza de eventos de cada stack es append-only y cada entrada registra el actor que la provocó — el usuario del portal (user:…) o la API key (api-key:…) — incluso tras eliminar el stack. Los eventos nunca contienen valores sensibles.

Concurrencia segura

Un stack en despliegue actúa como mutex: intentos concurrentes de ejecutar, proponer o eliminar reciben 409 en lugar de pisarse. Proponer un changeset nuevo reemplaza (superseded) al pendiente anterior, pero jamás a uno en ejecución.