Configurar OpenID Connect en Amazon Web Services

Información general

OpenID Connect (OIDC) permite que tus flujos de trabajo de GitHub Actions accedan a los recursos de Amazon Web Services (AWS) sin necesidad de almacenar las credenciales de AWS como secretos de GitHub de larga duración.

En esta guía se explica cómo configurar AWS para que confíe en el OIDC de GitHub como una entidad federada y se incluye un ejemplo de flujo de trabajo para aws-actions/configure-aws-credentials en el que se usan tokens para autenticarse en AWS y acceder a los recursos.

Prerrequisitos

• Para conocer los conceptos básicos de cómo GitHub usa OpenID Connect (OIDC) y su arquitectura y ventajas, consulta "Acerca del fortalecimiento de seguridad con OpenID Connect".

• Antes de proceder, debes planear tu estrategia de seguridad para garantizar que los tokens de acceso solo se asignen de forma predecible. Para controlar la forma en que el proveedor de servicios en la nube emite tokens de acceso, tendrá que definir al menos una condición, para que los repositorios no confiables no puedan solicitar tokens de acceso para los recursos en la nube. Para obtener más información, vea «Acerca del fortalecimiento de seguridad con OpenID Connect».

Agregar el proveedor de identidad a AWS

Para agregar el proveedor de OIDC de GitHub a IAM, vea la documentación de AWS.

• Para la dirección URL del proveedor: usa https://HOSTNAME/_services/token
• Para "Público": utilice sts.amazonaws.com si usa la acción oficial.

Configurar el rol y política de confianza

Para configurar el rol y la confianza en IAM, vea la documentación de AWS sobre "Asumir un rol" y "Creación de un rol para la identidad web o la federación de OpenID Connect".

Edite la directiva de confianza para agregar el campo sub a las condiciones de validación. Por ejemplo:

"Condition": {
  "StringEquals": {
    "HOSTNAME/_services/token:aud": "sts.amazonaws.com",
    "HOSTNAME/_services/token:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
  }
}

En el ejemplo siguiente, StringLike se usa con un operador comodín (*) para permitir que cualquier rama, rama de combinación de solicitudes de incorporación de cambios o entorno del repositorio y la organización octo-org/octo-repo asuman un rol en AWS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
                },
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Actualizar tu flujo de trabajo de GitHub Actions

Para actualizar tus flujos de trabajo para ODIC, necesitarás hacer dos cambios a tu YAML:

1. Agregar ajustes de permisos para el token.
2. Use la acción aws-actions/configure-aws-credentials para intercambiar el token de OIDC (JWT) por un token de acceso a la nube.

Agregar ajustes de permisos

 La ejecución del trabajo o del flujo de trabajo necesita una configuración permissions con id-token: write. No podrá solicitar el token de identificador JWT de OIDC si el valor permissions de id-token está establecido en read o none.

El valor id-token: write permite solicitar JWT desde el proveedor OIDC de GitHub mediante uno de estos enfoques:

• Con variables de entorno en el ejecutor (ACTIONS_ID_TOKEN_REQUEST_URL y ACTIONS_ID_TOKEN_REQUEST_TOKEN).
• Con getIDToken() del kit de herramientas de Acciones.

Si necesita capturar un token de OIDC para un flujo de trabajo, el permiso se puede establecer en el nivel de flujo de trabajo. Por ejemplo:

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read  # This is required for actions/checkout

Si solo necesitas recuperar un token de OIDC para un solo job, entonces este permiso puede configurarse dentro de dicho job. Por ejemplo:

permissions:
  id-token: write # This is required for requesting the JWT

Puede que necesites especificar permisos adicionales aquí, dependiendo de los requisitos de tu flujo de trabajo.

Para los flujos de trabajo reutilizables, la configuración de permissions para id-token debe fijarse en write en el nivel del flujo de trabajo que llama o en el trabajo específico que llama al flujo de trabajo reutilizable. Para obtener más información, vea «Reutilización de flujos de trabajo».

Solicitar el token de acceso

La acción aws-actions/configure-aws-credentials recibe un JWT del proveedor de OIDC de GitHub y luego solicita un token de acceso a AWS. Para más información, vea la documentación de AWS.

• <example-bucket-name>: agregue aquí el nombre del cubo de S3.
• <role-to-assume>: reemplace el ejemplo por el rol de AWS.
• <example-aws-region>: agregue aquí el nombre de la región de AWS.

# Sample workflow to access AWS resources when workflow is tied to branch
# The workflow Creates static website using aws s3
name: AWS example workflow
on:
  push
env:
  BUCKET_NAME : "<example-bucket-name>"
  AWS_REGION : "<example-aws-region>"
# permission can be added at job level or workflow level    
permissions:
      id-token: write   # This is required for requesting the JWT
      contents: read    # This is required for actions/checkout
jobs:
  S3PackageUpload:
    runs-on: ubuntu-latest
    steps:
      - name: Git clone the repository
        uses: actions/checkout@v3
      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::1234567890:role/example-role
          role-session-name: samplerolesession
          aws-region: ${{ env.AWS_REGION }}
      # Upload a file to AWS s3
      - name:  Copy index.html to s3
        run: |
          aws s3 cp ./index.html s3://${{ env.BUCKET_NAME }}/