GitHub Actions and AWS: designing deployments with OIDC
Temporary identity, scoped trust policies and a clear boundary between building and deploying.
A pipeline does not need to become a store of permanent credentials to deploy to AWS. OIDC offers a trust relationship between GitHub Actions and an IAM role. The important questions become which workflow can assume that role and what it can do afterwards.
Two policies, two responsibilities
The trust policy determines who can assume the role. The permissions policy determines what the resulting session can do. Restricting trust cannot compensate for excessive permissions, and minimal permissions are not enough if any repository can obtain them.
AWS requires conditions on the sub when trusting GitHub’s OIDC provider. In the lab design, I would limit the repository and deployment environment and validate the expected audience. The exact values depend on whether the workflow uses branches, pull requests or GitHub environments.
Building and deploying have different needs
A job that runs tests and builds an image needs different permissions from a job that updates a service. Separating them reduces how much code receives access to the target environment. An image digest precisely identifies the artifact being promoted.
The id-token: write permission lets a workflow request an OIDC token; it does not itself grant AWS permissions. Those depend on the role’s trust and permission policies.
Test denied access too
A useful test verifies that an unauthorized branch cannot assume the role. Another confirms that a build job has no deployment permissions. Both teach us more about actual boundaries than a single successful run.
For production, I would also document environment approvals, workflow change review and the strategy for pinning actions to reviewed revisions. Temporary identity reduces reliance on permanent secrets but does not remove the need to review code and permissions.
Evidence to attach
One allowed run, one denied run and the relationship between commit, image and environment. This portfolio presents the pipeline as a design; execution records can be added when an executable lab exists.
References
Un pipeline no necesita convertirse en un almacén de credenciales permanentes para desplegar en AWS. OIDC permite plantear una relación de confianza entre GitHub Actions y un rol de IAM. La pregunta importante pasa a ser qué ejecución puede asumir ese rol y qué podrá hacer después.
Dos políticas, dos responsabilidades
La política de confianza determina quién puede asumir el rol. La política de permisos determina qué puede hacer la sesión resultante. Una confianza bien restringida no compensa unos permisos excesivos, y unos permisos mínimos no sirven si cualquier repositorio puede obtenerlos.
AWS exige condiciones sobre el sub cuando se confía en el proveedor OIDC de GitHub. En el diseño del laboratorio limitaría el repositorio y el entorno de despliegue, además de validar la audiencia esperada. Los valores concretos dependen de si el workflow usa ramas, pull requests o entornos de GitHub.
Construir no es desplegar
El job que ejecuta pruebas y construye una imagen necesita permisos diferentes al que actualiza un servicio. Separarlos reduce la cantidad de código que recibe acceso al entorno de destino. El digest de la imagen ofrece una referencia precisa del artefacto que se promueve.
Los permisos id-token: write permiten solicitar el token OIDC dentro del workflow; no conceden por sí solos permisos en AWS. Estos dependen de la confianza y las políticas del rol.
Probar también la denegación
Una prueba útil verifica que una rama no autorizada no pueda asumir el rol. Otra confirma que un job de construcción no tenga permisos de despliegue. Ambas enseñan más sobre los límites reales que una única ejecución exitosa.
En producción documentaría además las aprobaciones del entorno, la revisión de cambios del workflow y la estrategia para fijar actions a revisiones evaluadas. La identidad temporal reduce la dependencia de secretos permanentes, pero no elimina la necesidad de revisar código y permisos.
Evidencia que adjuntaría al caso
Una ejecución permitida, una denegada y la relación entre commit, imagen y entorno. En este portafolio el pipeline está presentado como diseño: esos registros se añadirán cuando exista un laboratorio ejecutable.