Compreender as identidades da 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 seus 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 Gerenciador de Recursos verifica se os recursos existem. Se não o fizerem, o Gestor de Recursos cria-os. Se já existirem recursos, o Resource Manager garante que a sua configuração corresponde à configuração especificada no ficheiro Bicep.

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

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

Até agora, você provavelmente implantou seus arquivos Bicep usando a CLI do Azure ou o Azure PowerShell. Quando você usa essas ferramentas, normalmente usa sua própria conta de usuário e autentica 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 seu modelo Bicep especifica.

Depois de mover para um fluxo de trabalho de implantação do GitHub Actions, você precisa 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 de usuário: um usuário representa um ser humano que geralmente entra interativamente usando um navegador. Os usuários geralmente têm verificações de segurança extras para executar quando entrarem, como autenticação multifator (MFA) e Acesso Condicional com base em seu local 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 juntos.
• Identidades de carga de trabalho: uma carga de trabalho é um processo ou sistema automatizado que geralmente não tem um humano executando-o diretamente. Uma carga de trabalho pode entrar no Microsoft Entra ID, mas não há nenhum humano 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 em identidades de carga de trabalho.

Identidades geridas

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.

As 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 para situações como automatizar o gerenciamento do Azure, conectar-se a bancos de dados e ler dados secretos do Cofre de Chaves do Azure. Você também 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. As identidades gerenciadas exigem que você possua e gerencie os recursos do Azure que executam suas implantações. Quando você trabalha com Ações do GitHub, geralmente confia na infraestrutura compartilhada que a Microsoft ou o GitHub fornece. No entanto, quando você usa uma identidade de carga de trabalho com as Ações do GitHub, pode obter o principal benefício das identidades gerenciadas: não precisa gerenciar nenhuma credencial.

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

Você pode se perguntar por que precisa criar esse novo tipo de objeto apenas para autenticar um fluxo de trabalho de implantação quando você tem contas de usuário que funcionam perfeitamente bem.

As contas de usuário não foram projetadas para uso autônomo. O processo de autenticação de uma conta de usuário geralmente verifica se um ser humano é a entidade que está tentando entrar. Cada vez mais, as organizações usam verificações de segurança extras 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 ele possa verificar a legitimidade de uma solicitação para entrar.

Os fluxos de trabalho são projetados para executar suas implantações, mesmo quando ninguém os está executando ativamente. Na verdade, a maioria dos benefícios dos fluxos de trabalho de implantação vem do fato de que eles são automatizados e não exigem 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, eles podem ser facilmente quebrados no futuro se o Microsoft Entra ID ou o administrador organizacional adicionar mais verificações de segurança ao seu processo de autenticação de usuário.

Por esses motivos, as tarefas internas de Ações do GitHub 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 um conceito de aplicativo, que representa um sistema, 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.

Quando você cria um aplicativo e informa o 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 suportado como o GitHub use um aplicativo Microsoft Entra.

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

Você também pode criar um objeto de entidade de serviço em seu locatário do 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 as aplicações estão estreitamente ligadas. Você usará uma entidade de serviço posteriormente neste módulo, quando conceder permissão ao seu fluxo de trabalho para acessar o Azure.