Creación de una identidad de carga de trabajo para un flujo de trabajo de Acciones de GitHub
Ahora que comprende el concepto de una identidad de carga de trabajo, puede preguntarse cómo crear una y unirla al flujo de trabajo GitHub Actions. Esta unidad le enseña los pasos para lograrlo.
Creación de una aplicación de Microsoft Entra
En la unidad anterior, ha aprendido que las identidades de carga de trabajo requieren la creación de un registro de aplicación en Microsoft Entra ID.
Nota:
Para crear y modificar los registros de la aplicación es necesario que tenga permisos en Microsoft Entra ID. En algunas organizaciones, es posible que necesite un administrador para realizar estos pasos.
Al crear un registro de aplicación, debe especificar un nombre para mostrar. El nombre para mostrar es un nombre legible que describe el registro de aplicación.
Sugerencia
Use un nombre para mostrar claro y descriptivo para el registro de aplicación. Es importante ayudar a su equipo a comprender para qué es el registro de aplicación, para que nadie la elimine accidentalmente o cambie sus permisos.
Este es un comando de ejemplo de la CLI de Azure para crear una nueva aplicación de Microsoft Entra:
az ad app create --display-name $applicationRegistrationName
Este es un comando de ejemplo de Azure PowerShell para crear una nueva aplicación de Microsoft Entra:
New-AzADApplication -DisplayName $applicationRegistrationName
La salida del comando precedente incluye importante información, incluyendo:
- Id. de aplicación: el registro de la aplicación tiene un identificador único, a menudo denominado identificador de aplicación o, a veces, identificador de cliente. Use este identificador cuando su flujo de trabajo necesita iniciar sesión en Azure.
- Id. de objeto: El registro de la aplicación tiene un id. de objeto, el cual es un identificador único que Microsoft Entra ID asigna. Verá un ejemplo de cómo usar un identificador de objeto más adelante en este módulo.
Cuando crea un registro de aplicación, normalmente solo se establece el nombre de usuario para mostrar. Azure asigna automáticamente los demás nombres e identificadores.
Precaución
Un nombre para mostrar no es único. Es posible que varios registros de aplicación compartan el mismo nombre para mostrar. Tenga cuidado cuando conceda permisos a un registro de aplicación si está usando su nombre para mostrar para identificarlo. Puede conceder permisos accidentalmente a los registros de aplicación. En su lugar, se recomienda usar uno de los identificadores únicos.
Credenciales federadas
Cuando una identidad necesita comunicarse con Azure, inicia sesión en Microsoft Entra ID. Por sí mismo, un registro de aplicación no permite que un flujo de trabajo o una aplicación inicien sesión en Azure. Primero debe asignar algunas credenciales. Las credenciales federadas son un tipo de credencial de aplicación. A diferencia de la mayoría de credenciales, las credenciales federadas no requieren que administre secretos como contraseñas o claves.
Al crear una credencial federada para un flujo de trabajo de implementación, se indica eficazmente a Microsoft Entra ID y GitHub que tengan confianza mutua. Esta confianza se denomina federación.
A continuación, cuando su flujo de trabajo intente iniciar sesión, GitHub da información sobre la ejecución del flujo de trabajo para que Microsoft Entra ID pueda decidir si permite el intento de inicio de sesión. La información que GitHub proporciona a Microsoft Entra ID durante cada intento de inicio de sesión puede incluir los siguientes campos:
- El nombre de usuario o de organización de GitHub.
- El nombre del repositorio de GitHub.
- La rama del repositorio en la que se ejecuta actualmente el flujo de trabajo.
- El entorno al que se dirige el trabajo de flujo de trabajo. Obtendrá más información sobre los entornos en un módulo posterior.
- Si el flujo de trabajo se desencadenó al crear una solicitud de incorporación de cambios.
Puede configurar Microsoft Entra ID para permitir o denegar un intento de inicio de sesión desde GitHub, dependiendo de los valores de las propiedades enumeradas antes. Por ejemplo, puede aplicar las siguientes directivas:
- Permitir solo los intentos de inicio de sesión cuando un flujo de trabajo se ejecuta desde un repositorio específico de GitHub dentro de mi organización.
- Permitir solo los intentos de inicio de sesión cuando un flujo de trabajo se ejecuta desde un repositorio específico de GitHub dentro de mi organización y el nombre de rama es main.
Esta es una ilustración de cómo un flujo de trabajo de implementación puede iniciar sesión mediante una identidad de carga de trabajo y una credencial federada:
Los pasos implicados en el proceso de inicio de sesión son:
Cuando el flujo de trabajo necesita comunicarse con Azure, GitHub se pone en contacto de forma segura con Microsoft Entra ID para solicitar un token de acceso. GitHub proporciona información sobre la organización de GitHub (
my-github-user), el repositorio (my-repo) y la rama en la que se ejecuta el flujo de trabajo (main). También incluye el id. de inquilino en Microsoft Entra ID, el id. de aplicación del registro de aplicación de la identidad de flujo de trabajo y el id. de suscripción de Azure en el que el flujo de trabajo quiere implementar.Microsoft Entra ID valida el id. de la aplicación y comprueba si existe una credencial federada dentro de la aplicación para la organización, el repositorio y la rama de GitHub.
Una vez que Microsoft Entra ID determina que la solicitud es válida, emite un token de acceso. El flujo de trabajo usa el token de acceso cuando se comunica con Azure Resource Manager.
Creación de una credencial federada
Cuando use el CLI Azure, define una credencial federada al crear un archivo o una variable JSON. Por ejemplo, vea el siguiente archivo JSON:
{
"name": "MyFederatedCredential",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}
En ese archivo, la subjectpropiedad especifica que la credencial federada debería ser válida solo cuando un flujo de trabajo tenga las siguientes situaciones:
| Campo | Value |
|---|---|
| Nombre de la organización de GitHub | my-github-user |
| Nombre del repositorio de GitHub | my-repo |
| Nombre de la rama | main |
Después de crear una directiva en JSON y guardarla en un archivo llamadonorma.json, puede usar Azure CLI para crear la credencial federada:
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
Al usar Azure PowerShell, se define una credencial federada mediante la creación de una cadena similar a la siguiente:
$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"
La cadena anterior especifica que la credencial federada debería ser válida solo cuando se ejecuta un flujo de trabajo para las siguientes situaciones:
| Campo | Value |
|---|---|
| Nombre de la organización de GitHub | my-github-user |
| Nombre del repositorio de GitHub | my-repo |
| Nombre de la rama | main |
Después de crear una cadena de directiva, puede usar Azure PowerShell para crear la credencial federada:
New-AzADAppFederatedCredential `
-Name 'MyFederatedCredential' `
-ApplicationObjectId $applicationRegistrationObjectId `
-Issuer 'https://token.actions.githubusercontent.com' `
-Audience 'api://AzureADTokenExchange' `
-Subject $policy
Administración del ciclo de vida de la identidad de la carga de trabajo
Es importante considerar en cuenta todo el ciclo de vida de cada entidad de carga de trabajo que cree. Al crear una identidad de carga de trabajo para un flujo de trabajo de implementación, ¿qué ocurrirá si el flujo de trabajo se elimina o ya no se usa?
Las identidades de trabajo y las credenciales federadas no se eliminan de forma automática, por lo que necesita auditar y eliminar las antiguas. Aunque las identidades de carga de trabajo del flujo de trabajo de implementación no tienen credenciales secretas que se podrían reutilizar, es mejor quitarlas cuando ya no sean necesarias. De esa forma, no hay posibilidad de que alguien pueda crear otro repositorio de GitHub con el mismo nombre y de forma inesperada consiga acceso a su entorno Azure.
Se recomienda documentar las identidades de carga de trabajo en un lugar al que usted y su equipo puedan acceder fácilmente. Incluya la siguiente información para cada identidad de carga de trabajo:
- Información clave de identificación, como su nombre e ID de la aplicación
- Su propósito
- Quien lo creó, quien es el responsable de gestionarlo, y quien podría tener las respuestas si hay un problema
- Los permisos que necesita y una justificación clara de por qué los necesita
- Su duración prevista
Debe auditar periódicamente las identidades de carga de trabajo para asegurarse de que se siguen utilizando y de que los permisos que se les han asignado siguen siendo correctos.