Conceder acesso à entidade de serviço ao Azure

Concluído

Por si só, uma entidade de serviço não pode fazer nada em seu ambiente do Azure. É da mesma forma que um usuário, que não pode trabalhar com seus recursos do Azure a menos que esteja autorizado a fazer isso. Nesta unidade, você aprenderá a autorizar as entidades de serviço a implantar e configurar recursos do Azure, evitando a concessão de permissões desnecessárias.

Observação

Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você praticará o que aprendeu aqui em breve.

Autorização da entidade de serviço

Até agora, você se concentrou em saber o que são as entidades de serviço e como elas podem ser usadas para provar a identidade de um pipeline para o Microsoft Entra ID. Trata-se de autenticação.

Depois de o Microsoft Entra ID autenticar uma entidade de serviço, a próxima pergunta é: o que essa entidade de serviço pode fazer? Esse é o conceito de autorização. É responsabilidade do sistema de controle de acesso baseado em função do Azure (RBAC), às vezes chamado de IAM (gerenciamento de identidades e acesso). Usando o RBAC do Azure, você pode conceder a uma entidade de serviço acesso a um grupo de recursos, a uma assinatura ou a um grupo de gerenciamento específicos.

Observação

Tudo o que você está fazendo aqui é usar o sistema RBAC do Azure para conceder o acesso para criar e gerenciar recursos do Azure, como suas contas de armazenamento, o plano do Serviço de Aplicativo e as redes virtuais. O Microsoft Entra ID também tem seu próprio sistema de funções, que às vezes é chamado de funções do diretório. Você usa essas funções para conceder permissões para as entidades de serviço gerenciarem o Microsoft Entra ID. Este módulo não aborda esse assunto detalhadamente, mas esteja ciente de que o termo função pode ser usado para ambas as situações em algumas documentações.

Selecionar a atribuição de função certa para seu pipeline

Uma atribuição de função tem três partes principais: a quem a função é atribuída (o destinatário), o que eles podem fazer (a função), e a quais recurso ou recursos a atribuição de função se aplica (o escopo).

Atribuição

Ao trabalhar com uma entidade de serviço, você atribui funções para ela. Você usa a ID do aplicativo da entidade de serviço para identificar a entidade de serviço certa para esse destinatário.

Função

Pode dar um pouco mais de trabalho descobrir a qual função atribuir. No Azure, há algumas funções comuns:

• Leitor, que permite que o destinatário leia informações sobre recursos, mas não os modifique ou exclua.
• Colaborador, que permite que o destinatário crie recursos, e leia e modifique os recursos existentes. No entanto, os colaboradores não podem conceder a outras entidades de segurança o acesso aos recursos.
• Proprietário, que permite controle total sobre os recursos, incluindo a concessão de acesso a outras entidades de segurança.

Cuidado

Você deve conceder às entidades de serviço somente as permissões mínimas de que elas precisem para fazer seus trabalhos. Na maioria das vezes, a função Proprietário é muito permissiva para um pipeline de implantação.

Também há muitas funções específicas que fornecem acesso apenas a um subconjunto de funcionalidades. Você pode até mesmo criar sua definição de função personalizada para especificar a lista exata de permissões que deseja atribuir.

Observação

Definições de função personalizadas podem ser uma maneira eficiente de conceder permissões para seus recursos do Azure, mas podem ser difíceis de trabalhar. Nem sempre é fácil determinar exatamente quais permissões você precisa adicionar a uma definição de função personalizada, e você pode acidentalmente tornar as definições de função muito restritivas ou muito permissivas. Se você não tiver certeza do que fazer, é melhor usar uma das definições de função internas. Definições de função personalizadas não são o escopo deste módulo.

Escopo

Você precisa determinar a amplitude da função que você irá atribuir. Essa decisão afeta o número de recursos que a entidade de serviço pode modificar. Os escopos comuns incluem:

• Recurso único: você pode conceder acesso apenas a um recurso específico. Normalmente, os pipelines de implantação não usam esse escopo porque um pipeline cria recursos que ainda não existem, ou reconfigura vários recursos.
• Grupo de recursos: você pode conceder acesso a todos os recursos em um grupo de recursos. Os colaboradores e os proprietários também podem criar recursos dentro do grupo. Essa é uma boa opção para muitos pipelines de implantação.
• Assinatura: você pode conceder acesso a todos os recursos em uma assinatura. Se você tiver vários aplicativos, cargas de trabalho ou ambientes em uma única assinatura, poderá conceder permissões ao escopo da assinatura. No entanto, isso geralmente é muito permissivo para um pipeline de implantação. Alternativamente, você deve considerar o escopo de suas atribuições de função para grupos de recursos, a menos que seu fluxo de trabalho de implantação precise criar grupos de recursos por conta própria.

Lembre-se de que as atribuições de função são herdadas. Se você atribuir uma função a uma assinatura, o destinatário terá acesso a todo recurso e grupos de recursos dentro dessa assinatura.

Selecionar a atribuição de função correta

Agora que você entendeu os componentes de uma atribuição de função, você pode decidir os valores apropriados para seus cenários. Aqui estão algumas diretrizes gerais para serem consideradas:

• Use a função menos permissiva que você puder. Se seu pipeline só vai implantar modelos Bicep básico, e não gerenciará atribuições de função, não use a função Proprietário.
• Use o escopo mais restritivo que você puder. A maioria dos pipelines só precisa implantar recursos em um grupo de recursos, portanto, eles não devem receber atribuições de função no escopo da assinatura.
• Para muitos pipelines, uma boa opção padrão para uma atribuição de função é a função de colaborador no escopo do grupo de recursos.
• Considere tudo o que seu pipeline faz e tudo o que ele poderá fazer no futuro. Por exemplo, você pode considerar a criação de uma definição de função personalizada para o pipeline de implantação do site e conceder permissões somente para o Serviço de Aplicativo e para o Application Insights. No próximo mês, talvez seja necessário adicionar uma conta de Azure Cosmos DB ao arquivo Bicep, mas a função personalizada bloqueará que se criem recursos do Azure Cosmos DB. Em vez disso, é geralmente melhor usar uma função interna, ou uma combinação de funções internas, para evitar ter de alterar repetidamente suas definições de função. Considere o uso do Azure Policy para impor seus requisitos de governança aos serviços, SKUs e locais permitidos.
• Teste o pipeline para verificar se a atribuição de função funciona.

Combinar e mesclar atribuições de função

Você pode criar várias atribuições de função que fornecem permissões diferentes em escopos diferentes. Por exemplo, você pode atribuir a uma entidade de serviço a função de Leitor com um escopo de toda a assinatura e, em seguida, atribuir separadamente à mesma entidade de serviço a função de Colaborador para um grupo de recursos específico. Quando a entidade de serviço tenta trabalhar com o grupo de recursos, a atribuição mais permissiva é aplicada.

Trabalhando com vários ambientes

É provável que você trabalhe com vários ambientes, como ambientes de desenvolvimento, teste e produção para seus aplicativos. Os recursos para cada ambiente devem ser implantados em diferentes grupos de recursos ou assinaturas.

Você deve criar entidades de serviço separadas para cada ambiente, e conceder a cada entidade de serviço o conjunto mínimo de permissões necessárias para suas implantações. Seja especialmente cuidadoso para evitar a combinação de permissões para implantações de produção com permissões para implantações em ambientes de não produção.

Criar uma atribuição de função para a entidade de serviço

Para criar uma atribuição de função para uma entidade de serviço, use o comando az role assignment create. Você precisa especificar o destinatário, a função e o escopo:

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Vamos examinar cada argumento:

• --assignee especifica a entidade de serviço. Para evitar ambiguidade, é uma boa prática usar a ID do aplicativo.
• --role especifica a função. Se você usar uma função interna, poderá especificá-la pelo nome. Se você usar uma definição de função personalizada, especifique a ID de definição da função completa.
• --scope especifica o escopo. Normalmente, é uma ID de recurso para um único recurso, um grupo de recursos ou uma assinatura.
• --description é uma descrição legível da atribuição de função.

Para criar uma atribuição de função para uma entidade de serviço, use o cmdlet New-AzRoleAssignment. Você precisa especificar o destinatário, a função e o escopo:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Vamos examinar cada argumento:

• -ApplicationId especifica a ID de registro do aplicativo da entidade de serviço.
• -RoleDefinitionName especifica o nome de uma função interna. Se, em vez disso, você usar uma definição de função personalizada, especifique a ID de definição de função completa usando o argumento -RoleDefinitionId.
• -Scope especifica o escopo. Normalmente, é uma ID de recurso para um único recurso, um grupo de recursos ou uma assinatura.
• -Description é uma descrição legível da atribuição de função.

Dica

É uma prática recomendada fornecer uma justificativa para suas atribuições de função, especificando uma descrição. Uma descrição ajuda qualquer pessoa que revisa as atribuições de função posteriormente entender sua finalidade e como você decidiu sobre o destinatário, a função e o escopo.

Observação

As atribuições de função podem levar alguns minutos para se tornarem ativas.

Criar uma entidade de serviço e uma atribuição de função em uma única operação

Você também pode criar uma atribuição de função ao mesmo tempo em que cria uma entidade de serviço. O código é semelhante ao comando que você usou para criar uma entidade de serviço nas unidades anteriores, mas com alguns argumentos adicionais:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

Conceder acesso usando Bicep

As atribuições de função são recursos do Azure. Isso significa que você pode criar uma atribuição de função usando Bicep. Você pode fazer isso se inicializar os grupos de recursos usando o Bicep e, em seguida, implantar os recursos no grupo de recursos usando uma entidade de serviço. Aqui está um exemplo de definição de Bicep para a atribuição de função acima:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Vamos examinar cada argumento:

• name é um identificador exclusivo para a atribuição de função. Ele deve estar na forma de um GUID (identificador global exclusivo). É uma boa prática usar a função guid() no Bicep para criar um GUID, e usar a ID da entidade de segurança, a ID da definição de função e o escopo como os argumentos semente para a função, a fim de garantir que você crie um nome exclusivo para cada atribuição de função.
• principalType deve ser definido como ServicePrincipal.
• roleDefinitionId é a ID de recurso totalmente qualificado para a definição de função que você está atribuindo. Na maioria das vezes, você trabalhará com funções internas e poderá encontrar a ID de definição de função na documentação de funções internas do Azure. Por exemplo, a função Colaborador tem a ID de definição de função b24988ac-6180-42a0-ab88-20f7382dd24c. Ao especificá-la no arquivo Bicep, você a expressa usando uma ID de recurso totalmente qualificado, como /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
• principalId é a ID de objeto da entidade de serviço. Certifique-se de não usar a ID do aplicativo ou a ID de objeto do registro do aplicativo.
• description é uma descrição legível da atribuição de função.