Entender 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 os recursos do Azure. No 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 Resource Manager verifica se os recursos existem. Se não existirem, o Resource Manager os criará. Se já existir algum recurso, o Resource Manager garantirá que a configuração desse recurso corresponda à configuração que você especificar no modelo.
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 modelo contém. Para implantar o modelo 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 consideradas 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 modelos 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 mover para um pipeline, você precisa usar um tipo diferente de identidade porque o próprio pipeline executa implantações, sem 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 uma pessoa que normalmente entra de forma interativa usando um navegador. Os usuários geralmente precisam executar verificações de segurança adicionais ao entrar, como a MFA (autenticação multifator) e o Acesso Condicional com base na localização ou na 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.
- Uma entidade de serviço representa um processo ou sistema automatizado que, normalmente, não tem uma pessoa executando-o diretamente.
- Uma identidade gerenciada é um tipo especial de entidade de serviço projetada para situações em que uma pessoa não esteja envolvida no processo de autenticação.
Entidades de serviço
Uma entidade de serviço é um tipo de conta. Ele pode entrar no Microsoft Entra ID, mas nenhum ser humano está presente para entrar e interagir com o processo de autenticação. As entidades de serviço não têm MFA ou proteções semelhantes, pois elas exigem que uma pessoa faça algo para provar sua identidade.
No Microsoft Entra ID, uma entidade de serviço é identificada por uma ID de aplicativo e uma credencial. A ID do aplicativo é uma ID globalmente exclusiva (GUID). Para pipelines, a credencial geralmente é uma senha forte chamada chave. Como alternativa, você pode usar um certificado como credencial.
Identidades gerenciadas
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.
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ê também pode usar identidades gerenciadas com o Azure Arc para outros cenários.
Quando você trabalha com pipelines, geralmente não é possível usar 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 Azure Pipelines, geralmente depende de infraestrutura compartilhada fornecida pela Microsoft.
Observação
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 sua própria máquina virtual baseada no Azure. Como você possui a máquina virtual, você pode atribuir a ela uma identidade gerenciada e usá-la em seu pipeline.
No entanto, na maioria das vezes seus pipelines são executados usando um agente hospedado, que é um servidor que a Microsoft gerencia. No momento, agentes hospedados não são compatíveis com identidades gerenciadas.
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. 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ê deve estar imaginando por que precisa criar todo 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 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 adicionais durante a autenticação. Essas verificações incluem a MFA, verificações tipo 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 entrada.
Os pipelines são projetados para executar suas implantações mesmo quando ninguém estiver as 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 se conectar, 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 pipeline 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 as entidades de serviço funcionam?
Você pode ver alguns termos diferentes sendo usados ao trabalhar 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 saber 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 o conceito de um aplicativo, que representa um sistema, parte de software, processo ou algum outro agente não humano. Você pode considerar 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 de autenticação e implantações do pipeline. 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.
As entidades de serviço e os aplicativos estão intimamente ligados. Sempre que um registro de aplicativo é adicionado a um locatário do Microsoft Entra, um objeto de entidade de serviço é criado nesse locatário do Microsoft Entra. Ao examinar uma entidade de serviço no portal do Azure, você vê muitas outras funcionalidades e configurações que podem não parecer relevantes. Grande parte disso é 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, ao mesmo tempo, um registro de aplicativo. Então, pode ser que você não perceba que há 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 para uma identidade gerenciada.
Observação
Às vezes, uma entidade de serviço é chamada de aplicativo empresarial. Algumas ferramentas usam um nome, e outras ferramentas usam outro nome. Você também pode ver entidades de serviço chamadas de aplicativos gerenciados em seu diretório local, mas elas não são a mesma coisa que as identidades gerenciadas.
Para resumir, ao criar uma entidade de serviço, primeiro você cria um registro de aplicativo, e depois cria uma entidade de serviço para esse registro de aplicativo usar. A maioria das ferramentas com as quais você trabalha fará isso para você, então você nem se preocupa com isso. Talvez você não use todos os recursos dos aplicativos do Microsoft Entra ao trabalhar com pipelines de implantação. Mesmo assim, como as entidades de serviço estão relacionadas a aplicativos, aplica-se a mesma estrutura de objetos do Microsoft Entra.