El error AccessDenied en GitHub Actions y AWS suele ser de confianza, no de permisos
Aumentar los permisos de servicio no soluciona un fallo en la autenticación OIDC. El problema habitual está en la política de confianza del rol.
Cuando un workflow de GitHub Actions falla al asumir un rol de AWS mediante OpenID Connect, el instinto natural es revisar los permisos adjuntos al rol. Eso suele apuntar a la capa equivocada. El fallo de sts:AssumeRoleWithWebIdentity es una decisión de identidad y confianza: AWS evalúa si la identidad OIDC entrante está autorizada a obtener el rol antes de que la sesión reciba los permisos de servicio. Si fallas aquí, ampliar permisos como s3:* o cloudformation:* no sirve de nada, porque esos permisos solo existen una vez emitida la sesión del rol. Añadir privilegios durante un fallo de OIDC aumenta la superficie de ataque sin corregir el control que falla.
La causa raíz suele ser un desajuste entre la identidad que presenta GitHub y la que permite la política de confianza de AWS. Los elementos clave son el proveedor OIDC para token.actions.githubusercontent.com, la audiencia esperada (habitualmente sts.amazonaws.com) y, sobre todo, el claim sub exacto.
Este último merece atención especial porque depende del contexto. Un trabajo que referencia un Environment de GitHub tiene un subject diferente al de una rama o pull request. Además, desde el 15 de julio de 2026, los repositorios de GitHub usan un formato de subject inmutable que incluye los IDs de propietario y repositorio. Los repositorios anteriores mantienen el formato basado en nombre a menos que opten por el nuevo. Si tu política de confianza se basa en un ejemplo antiguo con un subject hard-coded, fallará en repositorios nuevos o tras una transferencia.
Para corregirlo, mantén la política de confianza estrecha y asegúrate de que sus claims coincidan con la identidad real del workflow. Verifica que el job tenga permissions: id-token: write, que el proveedor OIDC exista en la cuenta de AWS, que el principal federado sea correcto y que las condiciones de aud y sub matcheen el contexto actual. Solo cuando la asunción del rol funcione, diagnostica los permisos de servicio.
Una regla práctica
Trata el trust de OIDC como un contrato testeable. Antes de desplegar, valida el formato del subject, la audiencia y el contexto. Para repositorios antiguos, documenta si usan el formato legado o el inmutable para evitar sorpresas en producción. Si el workflow no puede asumir el rol, el problema es de identidad. No amplíes permisos hasta que la asunción funcione. La verificación correcta es que el workflow obtiene la sesión en el contexto esperado, mientras que cualquier contexto fuera de la frontera de confianza sigue denegado.
