Un rol de mínimo privilegio en CloudFormation puede fallar en servicios adyacentes
CloudFormation no traduce cada recurso a una sola llamada API del mismo servicio: el proveedor consulta, asocia y etiqueta contra servicios vecinos, y el rol se queda corto al desplegar
Un rol de ejecución de CloudFormation diseñado para mínimo privilegio puede parecer impecable al compararlo línea a línea con los recursos de la plantilla y fallar igualmente durante el despliegue. El motivo es que CloudFormation no traduce cada tipo de recurso a una única llamada API del mismo servicio: la implementación del proveedor hace búsquedas, asociaciones, etiquetado y limpieza contra APIs de servicios vecinos. Si el rol se construyó solo con los nombres de servicio que se ven en la plantilla, una dependencia legítima del proveedor aparece como un AccessDenied que no esperabas.
El síntoma
La firma del fallo es reconocible: el stack llega a una operación de recurso válida y revienta en una acción de AWS que parece pertenecer a otro servicio distinto del que estás creando o asociando. Hay dos casos observados. La creación de un Application Load Balancer exigía ec2:GetSecurityGroupsForVpc. Y la asociación de un Web ACL necesitaba un permiso del lado del balanceador además de los permisos de WAF.
El primero desconcierta porque el recurso es de Elastic Load Balancing, la acción que falta es de EC2 y encima no es un Describe*. El segundo desconcierta porque la operación es conceptualmente WAF y sin embargo cruza la frontera de permisos entre WAF y balanceador.
La causa de fondo es un modelo de política construido sobre la titularidad del servicio en la plantilla, cuando la operación real del recurso depende del comportamiento del proveedor. En el caso del balanceador, el proveedor llamaba a la API actual de EC2 GetSecurityGroupsForVpc. La corrección puede ser tan estrecha como esto:
{
"Effect": "Allow",
"Action": "ec2:GetSecurityGroupsForVpc",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:RequestedRegion": "<AWS_REGION>" }
}
}
El Resource: "*" no significa que el rol tenga que ser amplio. Hay APIs de AWS que no ofrecen un scoping útil por ARN para esa petición. El mínimo privilegio sale entonces de conceder el conjunto de acciones más pequeño y aplicar las condiciones que sí estén soportadas.
Lo que no hay que hacer
La reacción habitual ante un denegado del proveedor es colgar una política gestionada amplia del servicio adyacente hasta que el despliegue pase. Resuelve la incertidumbre ampliando privilegio y tira a la basura la mejor pista disponible: AWS ya te dijo exactamente qué acción denegaba.
El procedimiento sensato es más aburrido. Capturar la acción y el recurso denegados. Identificar qué operación de CloudFormation estaba activa. Consultar la documentación vigente de esa ruta de integración y comprobar si la API admite scoping por recurso. Añadir solo la acción necesaria con la condición más fuerte posible, revisar un change set nuevo y dejar la dependencia anotada en un test estático del contrato de política.
El caso del Web ACL añade una advertencia: la evidencia histórica hay que revalidarla antes de reutilizarla. La denegación observada era elasticloadbalancing:SetWebACL, y la documentación actual de WAF distingue ese ajuste antiguo del Application Load Balancer de un modelo de asociación más reciente, con permisos CreateWebACLAssociation y DeleteWebACLAssociation del lado del balanceador junto a los de WAF. Eso no debilita la lección, la refuerza: las rutas de integración cambian, y la acción denegada hoy y la documentación de hoy son mejores entradas que una lista de permisos fijada para siempre.
La corrección se da por buena cuando la misma operación pasa con el rol estrecho y sin política amplia de por medio. Conviene cubrir también las rutas de actualización y borrado que el stack pueda ejecutar, no solo la de creación. Y el test de contrato debe fijar esa dependencia concreta para que un refactor posterior no la elimine en silencio.
Lo que debería haber cazado esto antes es un registro de dependencias de proveedor para los cambios de infraestructura protegida: por cada familia de recursos, qué acciones de servicios adyacentes han aparecido en documentación vigente o en despliegues validados. Versionado, no una tabla de verdad permanente. La pregunta útil cuando falla un despliegue de mínimo privilegio no es solo de qué servicio viene este recurso, sino qué APIs llama la operación actual para crearlo, asociarlo, inspeccionarlo, actualizarlo y borrarlo. Casi siempre lleva a una corrección más pequeña que adjuntar otra política amplia. El detalle de cómo se configura el rol de servicio está en la documentación de CloudFormation.
