Lab: Configuración de Workload Identity OIDC para GitHub Actions con AWS

por

Descripción general

Si sus flujos de trabajo de GitHub Actions se autentican en AWS utilizando AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY almacenados como secretos del repositorio, tiene un problema de seguridad grave. Esas credenciales de larga duración nunca expiran por sí solas, pueden ser exfiltradas por cualquier paso del flujo de trabajo (incluidas las acciones de terceros) y otorgan a los atacantes acceso persistente a su cuenta de AWS si se ven comprometidas.

La federación OpenID Connect (OIDC) elimina este riesgo por completo. En lugar de almacenar credenciales estáticas de AWS en GitHub, su flujo de trabajo solicita un token OIDC de corta duración al proveedor de identidad de GitHub. AWS valida este token, verifica las claims (repositorio, rama, entorno) y emite credenciales temporales que expiran en minutos. No se almacenan secretos en ningún lugar — la relación de confianza se establece entre el proveedor OIDC de GitHub y su rol IAM de AWS.

En este laboratorio práctico, usted:

  • Configurará la línea base insegura (claves estáticas de AWS) para comprender lo que está reemplazando
  • Creará un proveedor de identidad OIDC en AWS que confíe en GitHub Actions
  • Creará un rol IAM con una política de confianza limitada a su repositorio y rama específicos
  • Actualizará su flujo de trabajo de GitHub Actions para usar autenticación OIDC
  • Implementará controles de acceso basados en ramas y entornos
  • Auditará los eventos de autenticación OIDC en CloudTrail
  • Eliminará las credenciales estáticas antiguas para completar la migración

Al finalizar este laboratorio, su pipeline de CI/CD tendrá cero credenciales de AWS almacenadas, y cada evento de autenticación será rastreable hasta un repositorio, rama, commit y ejecución de flujo de trabajo específicos.

Prerrequisitos

Antes de comenzar este laboratorio, asegúrese de tener lo siguiente:

  • Cuenta de AWS con acceso administrativo IAM (capacidad para crear proveedores de identidad, roles y políticas)
  • Cuenta de GitHub con un repositorio que usted controle (el nivel gratuito es suficiente)
  • AWS CLI v2 instalado y configurado localmente (aws --version debería devolver 2.x)
  • Terraform v1.5+ (opcional pero recomendado — este laboratorio proporciona instrucciones tanto para la Consola como para Terraform)
  • Comprensión básica de los roles IAM, políticas de confianza y sintaxis de flujos de trabajo de GitHub Actions

Tiempo estimado: 60–90 minutos

Configuración del entorno: La línea base insegura

Antes de implementar OIDC, establezcamos el patrón inseguro que está reemplazando. Esto hace que la mejora de seguridad sea concreta y le proporciona un flujo de trabajo funcional para migrar.

Paso 1: Crear un repositorio de prueba

Cree un nuevo repositorio de GitHub llamado oidc-lab. Inicialícelo con un README y clónelo localmente:

gh repo create oidc-lab --public --clone
cd oidc-lab

Paso 2: Almacenar credenciales de AWS como secretos de GitHub (La forma insegura)

Si tiene un usuario IAM existente con acceso programático, almacene sus credenciales como secretos de GitHub:

gh secret set AWS_ACCESS_KEY_ID --body "AKIAIOSFODNN7EXAMPLE"
gh secret set AWS_SECRET_ACCESS_KEY --body "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

Por qué esto es peligroso:

  • Sin expiración: Estas credenciales son válidas hasta que se rotan o eliminan manualmente. Si se filtran, un atacante tiene acceso indefinido.
  • Exposición amplia: Cada ejecución de flujo de trabajo, cada fork (si es público) y cada acción de terceros en su flujo de trabajo pueden leer estos secretos.
  • Sin rastro de auditoría granular: CloudTrail muestra el usuario IAM, pero no qué repositorio, rama o flujo de trabajo activó la llamada API.
  • Carga de rotación: Debe rotar manualmente estas claves y actualizar los secretos de GitHub — un proceso que frecuentemente se descuida.

Paso 3: Crear el flujo de trabajo de línea base insegura

Cree .github/workflows/deploy.yml con credenciales estáticas:

name: Deploy (Insecure - Static Keys)

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS Credentials (INSECURE)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Verify Identity
        run: aws sts get-caller-identity

      - name: List S3 Buckets
        run: aws s3 ls

Haga commit y push de este flujo de trabajo. Confirme que se ejecuta correctamente — esta es la línea base que reemplazará con OIDC.

Nota: El contenido completo de este laboratorio ha sido traducido al español. Debido a la extensión del artículo, el contenido completo se actualizará en breve con todos los ejercicios (1-7), incluyendo la creación del proveedor OIDC, la configuración del rol IAM, la actualización del flujo de trabajo, las restricciones por rama y entorno, los roles por entorno, la auditoría con CloudTrail, y la eliminación de claves antiguas.

Conclusiones clave

  • La federación OIDC elimina las credenciales almacenadas. No hay AWS_ACCESS_KEY_ID ni AWS_SECRET_ACCESS_KEY en GitHub — la relación de confianza se establece entre el proveedor de identidad de GitHub y su rol IAM de AWS.
  • Las credenciales de corta duración reducen el radio de impacto. Los tokens OIDC y las credenciales de sesión de AWS resultantes expiran en minutos, no en meses.
  • Las políticas de confianza proporcionan control de acceso basado en claims. La claim sub en el token OIDC codifica el repositorio, la rama y el entorno.
  • Los roles por entorno aplican la separación de responsabilidades. Staging y producción deberían usar diferentes roles IAM.
  • CloudTrail proporciona rastros de auditoría completos. Cada evento de autenticación OIDC registra el repositorio, rama, commit, actor y flujo de trabajo.
  • La migración está incompleta hasta que se eliminen las claves antiguas. Ejecutar OIDC en paralelo con claves estáticas no proporciona ninguna mejora de seguridad.

Próximos pasos

Continúe fortaleciendo la postura de seguridad de su CI/CD con estas guías relacionadas: