Entenda as identidades de carga de trabalho

7 minutos

Fluxos de trabalho de implantação, aplicativos e software exigem uma maneira especial de autenticação. Nesta unidade, você aprenderá por que as identidades de carga de trabalho são importantes para fluxos de trabalho de implantação, como elas se encaixam no modelo de segurança do Azure e como funcionam.

Por que um fluxo de trabalho precisa ser autenticado?

Ao implantar um arquivo Bicep, você efetivamente pede ao Azure Resource Manager para criar ou modificar os recursos do Azure. No cenário de exemplo, você criou um arquivo Bicep para implantar o site da sua empresa de brinquedos. O arquivo Bicep declara recursos que incluem um plano do Serviço de Aplicativo do Azure, um aplicativo e uma instância do Application Insights.

Quando você implanta o arquivo, o Resource Manager verifica se os recursos existem. Se não existirem, o Resource Manager os criará. Se algum recurso já existir, o Resource Manager garantirá que sua configuração corresponda à configuração que você especificou no arquivo Bicep.

Todas essas operações exigem permissão, pois acessam e modificam os recursos do Azure. As permissões específicas necessárias para a implantação dependerão do que o arquivo Bicep contém. Para implantar o arquivo Bicep de exemplo para o site da sua empresa de brinquedos, você precisa ter as seguintes permissões no grupo de recursos em que está implantando:

A capacidade de criar implantações. As implantações são recursos com um tipo de Microsoft.Resources/deployments.
A capacidade de criar e modificar aplicativos e planos do Serviço de Aplicativo.
A capacidade de criar e modificar instâncias do Application Insights.

Até agora, você provavelmente implantou seus arquivos Bicep por conta própria usando a CLI do Azure ou o Azure PowerShell. Ao usar essas ferramentas, você normalmente usa sua própria conta de usuário e faz a autenticação usando seu navegador. Isso é chamado de usar sua própria identidade. Quando você envia uma implantação, o Azure verifica se sua identidade tem as permissões necessárias para fazer o que o modelo Bicep especifica.

Depois de mudar para um fluxo de trabalho de implantação do GitHub Actions, você precisará usar um tipo diferente de identidade, porque o fluxo de trabalho executa implantações sem o seu envolvimento direto.

Tipos de identidades

O Microsoft Entra ID é o serviço que gerencia identidades para o Azure. Alguns dos principais tipos de identidades são:

Identidades do usuário: um usuário representa um ser humano que geralmente faz login de forma interativa usando um navegador. Os usuários geralmente têm verificações de segurança extras para realizar quando entram, como MFA (autenticação multifator) e acesso condicional com base em sua localização ou rede.
Grupos: um grupo representa uma coleção de usuários. Os grupos não são autenticados diretamente, mas fornecem uma maneira conveniente de atribuir permissões a um conjunto de usuários.
Identidades de carga de trabalho: uma carga de trabalho é um processo ou sistema automatizado que geralmente não é executado diretamente por um humano. Ela pode entrar no Microsoft Entra ID, mas não há uma pessoa para entrar e interagir com o processo de autenticação. As identidades de carga de trabalho não têm MFA ou proteções semelhantes, porque esses recursos exigem que uma pessoa faça algo para provar sua identidade.

Este módulo se concentra nas identidades de carga de trabalho.

Identidades gerenciadas

Uma identidade gerenciada está associada a um recurso do Azure. O Azure gerencia as credenciais automaticamente. Quando o recurso precisa acessar algo, o Azure entra automaticamente usando as credenciais.

Identidades gerenciadas estão disponíveis para recursos hospedados no Azure, como máquinas virtuais e aplicativos do Serviço de Aplicativo. Eles são uma ótima maneira de os recursos do Azure se autenticarem em situações como na automatização do gerenciamento do Azure, na conexão com bancos de dados e na leitura de segredos do Azure Key Vault. Você pode usar identidades gerenciadas com o Azure Arc para outros cenários.

Quando você trabalha com fluxos de trabalho de implantação, geralmente não usa identidades gerenciadas. Isso ocorre porque as identidades gerenciadas exigem que você tenha e gerencie os recursos do Azure que executam suas implantações. Quando você trabalha com o GitHub Actions e o Azure Pipelines, geralmente depende de infraestrutura compartilhada fornecida pela Microsoft ou pelo GitHub. No entanto, ao usar uma identidade de carga de trabalho com GitHub Actions, você pode obter o principal benefício das identidades gerenciadas: você não precisa gerenciar nenhuma credencial.

Dica

Em outras partes da sua solução, se você tiver uma opção entre usar uma identidade gerenciada ou uma entidade de serviço normal, é melhor escolher uma identidade gerenciada. As identidades gerenciadas são mais fáceis de trabalhar e geralmente são mais seguras.

Por que você não pode simplesmente usar sua conta de usuário?

Talvez você se pergunte por que precisa criar todo esse novo tipo de objeto apenas para autenticar um fluxo de trabalho de implantação quando há contas de usuário que funcionam perfeitamente bem.

As contas de usuário não são projetadas para uso autônomo. O processo de autenticação para uma conta de usuário geralmente verifica se uma pessoa é a entidade que está tentando entrar. Cada vez mais as organizações estão usando verificações de segurança extra durante a autenticação. Essas verificações incluem MFA, verificações CAPTCHA e inspeção do dispositivo e da rede que o usuário está usando para que possam verificar a legitimidade de uma solicitação de login.

Os fluxos de trabalho são projetados para executar suas implantações mesmo quando não houver ninguém as executando ativamente. Na verdade, a maioria dos benefícios dos fluxos de trabalho de implantação vem do fato de serem automatizados e não exigirem interação humana.

Se você armazenar seu nome de usuário e senha em um fluxo de trabalho e tentar usá-los para entrar, eles provavelmente não funcionarão. Mesmo que pareçam funcionar, elas podem ser facilmente interrompidas no futuro caso o Microsoft Entra ID ou seu administrador organizacional adicionar mais verificações de segurança ao processo de autenticação do usuário.

Aviso

E também é uma má ideia salvar seu nome de usuário e senha em qualquer lugar, pois outra pessoa pode obter acesso a esses dados e usá-los se passando por você.

Por esses motivos, as tarefas internas do GitHub Actions que interagem com o Azure não permitem que você forneça as credenciais de uma conta de usuário. Eles exigem que você use uma identidade de carga de trabalho.

Como funcionam as identidades de carga de trabalho?

As identidades de carga de trabalho são um recurso do Microsoft Entra ID, que é um serviço de identidade global. Muitas empresas usam o Microsoft Entra ID, e cada empresa é chamada de locatário.

O Microsoft Entra ID tem o conceito de um aplicativo, que representa um sistema, parte de software, processo ou algum outro agente não humano. Você também pode pensar em um fluxo de trabalho de implantação como um aplicativo.

Ao criar um aplicativo e informar ao Microsoft Entra ID sobre ele, você cria um objeto chamado registro de aplicativo. Um registro de aplicativo representa o aplicativo no Microsoft Entra ID.

Um registro de aplicativo pode ter credenciais federadas associadas a ele. As credenciais federadas não exigem que você armazene segredos. Em vez disso, eles permitem que um serviço compatível, como o GitHub, use um aplicativo Microsoft Entra.

Quando seu fluxo de trabalho de GitHub Actions precisa ser autenticado, ele entra em contato com o Microsoft Entra ID por meio do GitHub. O GitHub informa ao Microsoft Entra ID o nome da organização e do repositório GitHub e, opcionalmente, algumas outras informações. Se você configurou uma credencial federada que corresponde aos detalhes do repositório, o Microsoft Entra autentica seu fluxo de trabalho de implantação. O fluxo de trabalho pode usar as permissões atribuídas ao aplicativo.

Dica

Ao examinar o registro de um aplicativo no portal do Azure, você verá muitas outras funcionalidades e configurações que podem não parecer relevantes. Isso ocorre porque os aplicativos podem fazer muitas coisas no Microsoft Entra ID que estão além do escopo das implantações de autenticação e fluxo de trabalho.

Você também pode criar um objeto de entidade de serviço em seu locatário Microsoft Entra. Uma entidade de serviço é como uma cópia do aplicativo para seu próprio locatário do Microsoft Entra usar. As entidades de serviço e os aplicativos estão intimamente ligados. Você usará uma entidade de serviço mais adiante neste módulo, ao conceder a permissão de fluxo de trabalho para acessar o Azure.

Observação