Criar uma identidade de carga de trabalho para um fluxo de trabalho do GitHub Actions
Agora que você entende o conceito de uma identidade de carga de trabalho, pode se perguntar como criar uma e vinculá-la a um fluxo de trabalho de implantação do GitHub Actions. Esta unidade mostra as etapas para realizar isso.
Criar um aplicativo Microsoft Entra
Na unidade anterior, você aprendeu que as identidades de carga de trabalho exigem a criação de um registro de aplicativo no Microsoft Entra ID.
Nota
Criar e modificar registros de aplicativos requer que você tenha permissões no Microsoft Entra ID. Em algumas organizações, você pode precisar de um administrador para executar essas etapas para você.
Ao criar um registro de aplicativo, você precisa especificar um nome para exibição. O nome para exibição é um nome legível por humanos que descreve o registro do aplicativo.
Gorjeta
Use um nome de exibição claro e descritivo para o registro do seu aplicativo. É importante ajudar sua equipe a entender para que serve o registro do aplicativo, para que ninguém o exclua acidentalmente ou altere suas permissões.
Aqui está um exemplo de comando da CLI do Azure para criar um novo aplicativo Microsoft Entra:
az ad app create --display-name $applicationRegistrationName
Aqui está um exemplo de comando do Azure PowerShell para criar um novo aplicativo Microsoft Entra:
New-AzADApplication -DisplayName $applicationRegistrationName
A saída do comando anterior inclui informações importantes, incluindo:
- ID do aplicativo: o registro do aplicativo tem um identificador exclusivo, geralmente chamado de ID do aplicativo ou, às vezes, de ID do cliente. Você usa esse identificador quando seu fluxo de trabalho precisa entrar no Azure.
- ID do objeto: O registro do aplicativo tem uma ID de objeto, que é um identificador exclusivo que o Microsoft Entra ID atribui. Você verá um exemplo de como usar um ID de objeto mais adiante neste módulo.
Quando você cria um registro de aplicativo, normalmente define apenas o nome para exibição. O Azure atribui os outros nomes e identificadores automaticamente.
Atenção
Um nome para exibição não é exclusivo. Vários registros de aplicativos podem compartilhar o mesmo nome para exibição. Tenha cuidado ao conceder permissões a um registro de aplicativo usando seu nome de exibição para identificá-lo. Você pode acidentalmente dar permissões para os registros de aplicativos errados. É uma boa prática usar um dos identificadores exclusivos.
Credenciais federadas
Quando uma identidade precisa se comunicar com o Azure, ela entra na ID do Microsoft Entra. Por si só, um registro de aplicativo não permite que um fluxo de trabalho ou aplicativo entre no Azure. Você precisa atribuir algumas credenciais primeiro. As credenciais federadas são um tipo de credencial de aplicativo. Ao contrário da maioria das credenciais, as credenciais federadas não exigem que você gerencie segredos como senhas ou chaves.
Ao criar uma credencial federada para um fluxo de trabalho de implantação, você efetivamente diz ao Microsoft Entra ID e ao GitHub para confiarem um no outro. Essa confiança é chamada de federação.
Em seguida, quando o fluxo de trabalho tenta entrar, o GitHub fornece informações sobre o fluxo de trabalho executado para que o Microsoft Entra ID possa decidir se permite a tentativa de entrada. As informações que o GitHub fornece ao Microsoft Entra ID durante cada tentativa de entrada podem incluir os seguintes campos:
- O nome do usuário ou da organização do GitHub.
- O nome do repositório GitHub.
- A ramificação do repositório na qual o fluxo de trabalho está sendo executado no momento.
- O ambiente ao qual seu trabalho de fluxo de trabalho se destina. Você aprenderá mais sobre ambientes em um módulo futuro.
- Se a criação de uma solicitação pull acionou o fluxo de trabalho.
Você pode configurar o ID do Microsoft Entra para permitir ou negar uma tentativa de entrada do GitHub, dependendo dos valores das propriedades listadas anteriormente. Por exemplo, você pode impor as seguintes políticas:
- Só permita tentativas de início de sessão quando um fluxo de trabalho é executado a partir de um repositório GitHub específico na minha organização.
- Só permita tentativas de entrada quando um fluxo de trabalho for executado a partir de um repositório GitHub específico dentro da minha organização e o nome da filial for principal.
Aqui está uma ilustração de como um fluxo de trabalho de implantação pode entrar usando uma identidade de carga de trabalho e uma credencial federada:
As etapas envolvidas no processo de entrada são:
Quando seu fluxo de trabalho precisa se comunicar com o Azure, o GitHub entra em contato com segurança com a ID do Microsoft Entra para solicitar um token de acesso. O GitHub fornece informações sobre a organização do GitHub (
my-github-user), o repositório (my-repo) e a ramificação na qual o fluxo de trabalho está sendo executado (main). Ele também inclui sua ID de locatário na ID do Microsoft Entra, a ID do aplicativo do registro do aplicativo da identidade do fluxo de trabalho e a ID de assinatura do Azure na qual seu fluxo de trabalho deseja implantar.O Microsoft Entra ID valida a ID do aplicativo e verifica se existe uma credencial federada dentro do aplicativo para a organização, repositório e ramificação do GitHub.
Depois que o Microsoft Entra ID determina que a solicitação é válida, ele emite um token de acesso. Seu fluxo de trabalho usa o token de acesso quando se comunica com o Gerenciador de Recursos do Azure.
Criar uma credencial federada
Ao usar a CLI do Azure, você define uma credencial federada criando um arquivo JSON ou variável. Por exemplo, observe o seguinte arquivo JSON:
{
"name": "MyFederatedCredential",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}
Nesse arquivo, a subject propriedade especifica que a credencial federada deve ser válida somente quando um fluxo de trabalho é executado para as seguintes situações:
| Campo | Value |
|---|---|
| Nome da organização do GitHub | my-github-user |
| Nome do repositório do GitHub | my-repo |
| Nome do ramo | main |
Depois de criar uma política em JSON e salvá-la em um arquivo chamado policy.json, você pode usar a CLI do Azure para criar a credencial federada:
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
Ao usar o Azure PowerShell, você define uma credencial federada criando uma cadeia de caracteres semelhante à seguinte:
$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"
A cadeia de caracteres anterior especifica que a credencial federada deve ser válida somente quando um fluxo de trabalho é executado para as seguintes situações:
| Campo | Value |
|---|---|
| Nome da organização do GitHub | my-github-user |
| Nome do repositório do GitHub | my-repo |
| Nome do ramo | main |
Depois de criar uma cadeia de caracteres de política, você pode usar o Azure PowerShell para criar a credencial federada:
New-AzADAppFederatedCredential `
-Name 'MyFederatedCredential' `
-ApplicationObjectId $applicationRegistrationObjectId `
-Issuer 'https://token.actions.githubusercontent.com' `
-Audience 'api://AzureADTokenExchange' `
-Subject $policy
Gerencie o ciclo de vida da identidade da sua carga de trabalho
É importante considerar todo o ciclo de vida de cada identidade de carga de trabalho criada. Quando você cria uma identidade de carga de trabalho para um fluxo de trabalho de implantação, o que acontecerá se o fluxo de trabalho for eventualmente excluído ou não for mais usado?
As identidades de carga de trabalho e as credenciais federadas não são removidas automaticamente, portanto, você precisa auditar e remover as antigas. Embora as identidades de carga de trabalho do fluxo de trabalho de implantação não tenham credenciais secretas que possam ser reutilizadas, ainda é melhor removê-las quando não forem mais necessárias. Dessa forma, não há nenhuma chance de que alguém possa criar outro repositório GitHub com o mesmo nome e obter acesso inesperadamente ao seu ambiente do Azure.
É uma boa prática documentar suas identidades de carga de trabalho em um local que você e sua equipe possam acessar facilmente. Inclua as seguintes informações para cada identidade de carga de trabalho:
- Principais informações de identificação, como nome e ID do aplicativo
- A sua finalidade
- Quem o criou, quem é responsável por gerenciá-lo e quem pode ter respostas se houver um problema
- As permissões de que precisa e uma justificação clara para o motivo pelo qual precisa delas
- Sua vida útil esperada
Você deve auditar regularmente suas identidades de carga de trabalho para garantir que elas ainda estejam sendo usadas e que as permissões atribuídas ainda estejam corretas.