Nota:
Actualmente los ejecutores hospedados por GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
Overview
OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in Azure, without needing to store the Azure credentials as long-lived GitHub secrets.
This guide gives an overview of how to configure Azure to trust GitHub's OIDC as a federated identity, and includes a workflow example for the azure/login
action that uses tokens to authenticate to Azure and access resources.
Prerequisites
-
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 más información, consulta Acerca del fortalecimiento de seguridad con OpenID Connect.
-
Debes asegurarte de que el proveedor de nube puede acceder a los siguientes puntos de conexión OIDC:
http://HOSTNAME/_services/token/.well-known/openid-configuration
http://HOSTNAME/_services/token/.well-known/jwks
Nota:
Microsoft Entra ID (previously known as Azure AD) does not have fixed IP ranges defined for these endpoints.
-
Make sure that the value of the issuer claim that's included with the JSON Web Token (JWT) is set to a publicly routable URL. For more information, see Acerca del fortalecimiento de seguridad con OpenID Connect.
Adding the federated credentials to Azure
GitHub's OIDC provider works with Azure's workload identity federation. For an overview, see Microsoft's documentation at Workload identity federation.
To configure the OIDC identity provider in Azure, you will need to perform the following configuration. For instructions on making these changes, refer to the Azure documentation.
- Create an Entra ID application and a service principal.
- Add federated credentials for the Entra ID application.
- Create GitHub secrets for storing Azure configuration.
Additional guidance for configuring the identity provider:
- For security hardening, make sure you've reviewed Acerca del fortalecimiento de seguridad con OpenID Connect. For an example, see Acerca del fortalecimiento de seguridad con OpenID Connect.
- For the
audience
setting,api://AzureADTokenExchange
is the recommended value, but you can also specify other values here.
Updating your GitHub Actions workflow
To update your workflows for OIDC, you will need to make two changes to your YAML:
- Add permissions settings for the token.
- Use the
azure/login
action to exchange the OIDC token (JWT) for a cloud access token.
Nota:
Cuando los entornos se usan en flujos de trabajo o en directivas de OIDC, se recomienda agregar reglas de protección al entorno para mayor seguridad. Por ejemplo, puedes configurar reglas de implementación en un entorno para restringir qué ramas y etiquetas se pueden implementar en el entorno o acceder a secretos del entorno. Para más información, consulta Managing environments for deployment.
Adding permissions settings
La ejecución de trabajo o flujo de trabajo requiere una configuración de permissions
con id-token: write
para permitir que el proveedor OIDC de GitHub pueda crear un token web JSON para cada ejecución. No podrás solicitar el token de identificador JWT de OIDC si el valor de permissions
para id-token
no está establecido en write
, pero este valor no implica conceder acceso de escritura a ningún recurso, solo poder capturar y establecer el token de OIDC para una acción o paso para habilitar la autenticación con un token de acceso de corta duración. Cualquier configuración de confianza real se define mediante notificaciones de OIDC. Para obtener más información, consulte Acerca del fortalecimiento de seguridad con OpenID Connect.
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
yACTIONS_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
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 trabajo único, entonces este permiso puede configurarse dentro de dicho job. Por ejemplo:
permissions: id-token: write # This is required for requesting the JWT
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 flujos de trabajo reutilizables que son propiedad del mismo usuario, organización o empresa que el flujo de trabajo del autor de la llamada, se puede acceder al token de OIDC generado en el flujo de trabajo reutilizable desde el contexto del autor de la llamada.
Para los flujos de trabajo reutilizables fuera de la empresa u organización, la configuración de permissions
para id-token
debe fijarse explícitamente en write
en el nivel del flujo de trabajo del autor de la llamada o en el trabajo específico que llama al flujo de trabajo reutilizable.
Esto garantiza que el token de OIDC generado en el flujo de trabajo reutilizable solo se pueda consumir en los flujos de trabajo de la persona que llama cuando está previsto.
Para más información, consulta Reusing workflows.
Requesting the access token
The azure/login
action receives a JWT from the GitHub OIDC provider, and then requests an access token from Azure. For more information, see the azure/login
documentation.
The following example exchanges an OIDC ID token with Azure to receive an access token, which can then be used to access cloud resources.
name: Run Azure Login with OIDC on: [push] permissions: id-token: write contents: read jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: 'Az CLI login' uses: azure/login@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: 'Run az commands' run: | az account show az group list
name: Run Azure Login with OIDC
on: [push]
permissions:
id-token: write
contents: read
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: 'Az CLI login'
uses: azure/login@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: 'Run az commands'
run: |
az account show
az group list