Compreender as entidades de serviço
As entidades de serviço fornecem uma maneira de autenticar pipelines, aplicativos e software. Nesta unidade, você aprenderá por que as entidades de serviço são importantes para os pipelines de implantação, como elas se encaixam no modelo de segurança do Azure e como funcionam.
Por que um pipeline precisa ser autenticado?
Ao implantar um modelo Bicep, você efetivamente pede ao Azure Resource Manager para criar ou modificar seus recursos do Azure. Neste cenário de exemplo, você criou um modelo Bicep para implantar o site da sua empresa de brinquedos. O modelo 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 modelo, o Gerenciador de Recursos verifica se os recursos existem. Se não o fizerem, o Gestor de Recursos cria-os. Se alguma já existir, o Resource Manager garante que sua configuração corresponda à configuração especificada no modelo.
Todas essas operações exigem permissões, porque acessam e modificam seus recursos do Azure. As permissões específicas necessárias para a implantação dependerão do conteúdo do modelo. Para implantar o modelo Bicep 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 consideradas recursos com um tipo de
Microsoft.Resources/deployments. - 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 modelos 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 pipeline, você precisa usar um tipo diferente de identidade porque o pipeline em si executa implantações, sem o seu envolvimento direto.
Tipos de entidades de segurança
O Microsoft Entra ID é o serviço que gerencia identidades para o Azure. O Microsoft Entra ID tem vários tipos de identidades, que também são chamadas de entidades de segurança:
- 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 adicionais para executar quando entrarem, como autenticação multifator (MFA) e Acesso Condicional com base em seu local ou rede.
- 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.
- Uma entidade de serviço representa um processo ou sistema automatizado que geralmente não tem um humano executando-o diretamente.
- Uma identidade gerenciada é um tipo especial de entidade de serviço projetada para situações em que um ser humano não está envolvido no processo de autenticação.
Principais de serviço
Uma entidade de serviço é um tipo de conta. Ele pode entrar no Microsoft Entra ID, mas não há nenhum humano para entrar e interagir com o processo de autenticação. As entidades de serviço não têm MFA ou proteções semelhantes, porque estas exigem que uma pessoa faça algo para provar a sua identidade.
No Microsoft Entra ID, uma entidade de serviço é identificada por uma ID de aplicativo e uma credencial. O ID do aplicativo é um GUID (ID globalmente exclusivo). Para pipelines, a credencial geralmente é uma senha forte chamada chave. Como alternativa, você pode usar um certificado como credencial.
Identidades geridas
Ao contrário dos outros tipos de entidades de serviço, uma identidade gerenciada não exige que você conheça ou mantenha suas credenciais. 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 pipelines, geralmente não pode usar identidades gerenciadas. Isso ocorre porque as identidades gerenciadas exigem que você possua e gerencie os recursos do Azure que executam suas implantações. Quando você trabalha com o Azure Pipelines, geralmente confia na infraestrutura compartilhada fornecida pela Microsoft.
Nota
Há algumas situações em que os pipelines podem usar identidades gerenciadas. No Azure Pipelines, você pode criar um agente auto-hospedado para executar os scripts e o código do pipeline usando em sua própria máquina virtual baseada no Azure. Como você possui a máquina virtual, pode atribuir-lhe uma identidade gerenciada e usá-la a partir do seu pipeline.
No entanto, na maioria das vezes, seus pipelines são executados usando um agente hospedado, que é um servidor gerenciado pela Microsoft. Atualmente, os agentes hospedados não são compatíveis com identidades gerenciadas.
Gorjeta
Em outras partes da sua solução, se você tiver a opção entre usar uma identidade gerenciada ou usar uma entidade de serviço normal, é melhor optar por uma identidade gerenciada. Eles são mais fáceis de trabalhar e geralmente são mais seguros.
Por que você não pode simplesmente usar sua conta de usuário?
Você pode se perguntar por que você precisa criar esse novo tipo de objeto apenas para autenticar um pipeline, 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 adicionais 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 pipelines são projetados para executar suas implantações mesmo quando ninguém os está executando ativamente. Na verdade, a maioria dos benefícios dos pipelines vem do fato de que eles são completamente automatizados e não exigem interação humana. Se você armazenar seu nome de usuário e senha em um pipeline 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.
Aviso
Também é uma má ideia salvar seu nome de usuário e senha em qualquer lugar, porque outra pessoa pode ter acesso a eles e, em seguida, usá-los para se passar por você.
Por esses motivos, as tarefas de pipeline internas 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 entidade de serviço.
Como funcionam as entidades de serviço?
Você pode ver alguns termos diferentes em uso quando trabalha com entidades de serviço ou com ferramentas como o portal do Azure ou a API do Microsoft Graph. Embora não seja essencial entender esses termos apenas para usar entidades de serviço em um pipeline, é útil conhecer um pouco sobre os conceitos.
As entidades de serviço são um recurso do Microsoft Entra ID. O Microsoft Entra ID é 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ê pode pensar em um pipeline de implantação como um aplicativo.
No Microsoft Entra ID, os aplicativos podem fazer muitas coisas que estão além do escopo da autenticação e das implantações de pipeline. 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.
As entidades de serviço e as aplicações estão estreitamente ligadas. Sempre que um registro de aplicativo é adicionado a um locatário do Microsoft Entra, um objeto principal de serviço é criado nesse locatário do Microsoft Entra. Quando você olha para uma entidade de serviço no portal do Azure, vê muitas outras funcionalidades e configurações que podem não parecer relevantes. Grande parte disso ocorre porque as entidades de serviço estão vinculadas a aplicativos.
Quando você cria uma entidade de serviço, a maioria das ferramentas que você usa também cria um registro de aplicativo ao mesmo tempo. Então você pode não notar que existem dois objetos diferentes.
Um tipo de entidade de serviço não está associado a um registro de aplicativo: uma identidade gerenciada. Como mencionado anteriormente, o Azure gerencia a configuração e as credenciais de uma identidade gerenciada.
Nota
Uma entidade de serviço às vezes é chamada de aplicativo empresarial. Algumas ferramentas usam um nome e outras usam o outro. Você também pode ver entidades de serviço chamadas aplicativos gerenciados em seu diretório local, mas elas não são a mesma coisa que identidades gerenciadas.
Para resumir, ao criar uma entidade de serviço, você primeiro cria um registro de aplicativo e, em seguida, cria uma entidade de serviço para esse registro de aplicativo usar. A maioria das ferramentas com as quais você trabalha fará isso por você, então você nem está ciente disso. Você pode não usar todos os recursos dos aplicativos Microsoft Entra quando trabalha com pipelines de implantação. Mesmo assim, como as entidades de serviço estão relacionadas a aplicativos, a mesma estrutura de objetos do Microsoft Entra se aplica.