Criar uma identidade de carga de trabalho para um fluxo de trabalho 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. Essa unidade mostra as etapas para fazer isso.
Criar um aplicativo do 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.
Observação
A criação e modificação de registros de aplicativos requerem permissões no Microsoft Entra ID. Em algumas organizações, talvez seja necessário um administrador para executar essas etapas para você.
Ao criar um registro de aplicativo, você precisará especificar um nome de exibição. O nome de exibição é um nome legível por humanos que descreve o registro do aplicativo.
Dica
Use um nome de exibição claro e descritivo para seu registro de aplicativo. É importante ajudar sua equipe a entender o que é o registro de aplicativo, para que ninguém a exclua acidentalmente ou altere suas permissões.
Aqui está um exemplo de comando da CLI do Azure para criar um novo aplicativo do Microsoft Entra:
az ad app create --display-name $applicationRegistrationName
Confira um exemplo de comando do Azure PowerShell para criar um novo aplicativo do Microsoft Entra:
New-AzADApplication -DisplayName $applicationRegistrationName
A saída do comando anterior inclui algumas informações importantes, incluindo:
- ID do aplicativo: o registro de aplicativo tem um identificador exclusivo, geralmente chamado de ID do aplicativo ou, às vezes, de ID do cliente. Use esse identificador quando o fluxo de trabalho precisar entrar no Azure.
- ID do Objeto: O registro de aplicativo tem uma ID de objeto, que é um identificador exclusivo atribuído pelo Microsoft Entra ID. Você verá um exemplo de como usar uma ID de objeto posteriormente neste módulo.
Ao criar um registro de aplicativo, você geralmente definirá apenas o nome de exibição. O Azure atribui os outros nomes e identificadores automaticamente.
Cuidado
Um nome de exibição não é exclusivo. Vários registros de aplicativo podem compartilhar o mesmo nome de exibição. Tenha cuidado ao conceder permissões a um aplicativo de serviço usando seu nome de exibição para identificá-lo. Você pode conceder permissões acidentalmente aos registros de aplicativo errados. É uma boa prática usar um dos identificadores exclusivos.
Credenciais federadas
Quando uma identidade precisa se comunicar com o Azure, ela se conecta ao Microsoft Entra ID. 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. 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.
Quando você cria uma credencial federada para um fluxo de trabalho de implantação, você efetivamente faz com que o Microsoft Entra ID e o GitHub confiem um no outro. Essa confiança é chamada de federação.
Então, quando seu fluxo de trabalho tenta se conectar, o GitHub fornece informações sobre a execução do fluxo de trabalho para que o Microsoft Entra ID possa decidir se permite a tentativa de conexão. As informações que o GitHub fornece ao Microsoft Entra ID durante cada tentativa de conexão podem incluir os seguintes campos:
- O nome do usuário ou da organização do GitHub.
- O nome do repositório GitHub.
- O branch do repositório no qual o fluxo de trabalho está sendo executado no momento.
- O ambiente que o trabalho do seu fluxo de trabalho tem como destino. Você aprenderá mais sobre ambientes em um módulo posterior.
- Se a criação de uma solicitação de pull disparou o fluxo de trabalho.
Você pode configurar o Microsoft Entra ID para permitir ou negar uma tentativa de conexão do GitHub, dependendo dos valores das propriedades listadas anteriormente. Por exemplo, você pode impor as seguintes políticas:
- Permitir somente tentativas de entrada quando um fluxo de trabalho for executado de um repositório GitHub específico em minha organização.
- Permitir tentativas de login apenas quando um fluxo de trabalho for executado a partir de um repositório GitHub específico em minha organização e o nome da ramificação 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 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 de forma segura com o Microsoft Entra ID para solicitar um token de acesso. GitHub fornece informações sobre a organização GitHub (
my-github-user), o repositório (my-repo) e a ramificação na qual o fluxo de trabalho está sendo executado (main). Também inclui o seu ID de inquilino no Microsoft Entra ID, o ID de aplicação do registo de aplicação da identidade do fluxo de trabalho e o ID de subscrição do Azure para o qual o seu fluxo de trabalho pretende implementar.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 branch 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 ele se comunica com o Azure Resource Manager.
Criar uma credencial federada
Ao usar a CLI do Azure, você define uma credencial federada criando um arquivo JSON ou uma variável. Por exemplo, examine 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 propriedade subject especifica que a credencial federada só deve ser válida quando um fluxo de trabalho é executado para as seguintes situações:
| Campo | Valor |
|---|---|
| Nome da organização do GitHub | my-github-user |
| Nome do repositório GitHub | my-repo |
| Nome do branch | main |
Depois de criar uma política no JSON e salvá-la em um arquivo chamado policy.json, você poderá usar a CLI do Azure para criar a credencial federada:
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
Ao usar Azure PowerShell, você definirá 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 só deve ser válida quando um fluxo de trabalho é executado para as seguintes situações:
| Campo | Valor |
|---|---|
| Nome da organização do GitHub | my-github-user |
| Nome do repositório GitHub | my-repo |
| Nome do branch | main |
Depois de criar uma cadeia de caracteres de política, você poderá 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
Gerenciar o ciclo de vida da sua identidade da carga de trabalho
É importante considerar todo o ciclo de vida de cada identidade de carga de trabalho que você criar. 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ê precisará 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 será recomendável removê-las quando elas não forem mais necessárias. Dessa forma, não há nenhuma chance de alguém criar outro repositório GitHub com o mesmo nome e obter acesso inesperado ao seu ambiente do Azure.
É uma prática recomendada documentar suas entidades da carga de trabalho em um lugar que você e sua equipe possam acessar facilmente. Inclua as seguintes informações para cada identidade de carga de trabalho:
- Informações de identificação de chave, como seu nome e a ID do aplicativo
- Sua finalidade
- Quem a criou, quem é responsável por gerenciá-la e quem pode ter respostas caso ocorra algum problema
- As permissões necessárias e uma justificativa clara do 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.