Conceder acesso a uma entidade de serviço ao Azure

  • 6 minutos

Por si só, uma entidade de serviço não pode fazer nada em seu ambiente do Azure. É como se um usuário não pudesse trabalhar com seus recursos do Azure, a menos que estivesse autorizado a fazê-lo. Nesta unidade, você aprenderá como autorizar entidades de serviço a implantar e configurar recursos do Azure, evitando conceder permissões desnecessárias.

Nota

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

Autorização da entidade de serviço

Até agora, você se concentrava em quais entidades de serviço sã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 que o Microsoft Entra ID autenticar uma entidade de serviço, a próxima pergunta se torna: o que essa entidade de serviço pode fazer? Este é o conceito de autorização. É responsabilidade do sistema RBAC (controle de acesso baseado em função) do Azure, às vezes chamado de gerenciamento de identidade e acesso (IAM). Usando o RBAC do Azure, você pode conceder a uma entidade de serviço acesso a um grupo de recursos, assinatura ou grupo de gerenciamento específico.

Nota

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

Selecione 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 cessionário), o que eles podem fazer (a função) e a que recurso ou recursos a atribuição de função se aplica (o escopo).

Cessionário

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

Role

Pode ser um pouco mais trabalhoso descobrir qual função atribuir. No Azure, há algumas funções comuns:

  • Reader, que permite ao cessionário ler informações sobre recursos, mas não modificá-los ou excluí-los.
  • Colaborador, que permite ao cessionário criar recursos e ler e modificar recursos existentes. No entanto, os colaboradores não podem conceder a outros responsáveis acesso aos recursos.
  • Proprietário, que permite o controle total sobre os recursos, incluindo a concessão de acesso a outras entidades de segurança.

Atenção

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

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

Nota

As definições de função personalizadas podem ser uma maneira poderosa 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. As definições de função personalizadas estão além do escopo deste módulo.

Âmbito

Você precisa determinar o quão amplamente você atribui a função. 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 dentro de um grupo de recursos. Colaboradores e 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 dentro de uma assinatura. Se você tiver vários aplicativos, cargas de trabalho ou ambientes em uma única assinatura, poderá conceder permissões para o escopo da assinatura. No entanto, isso geralmente é muito permissivo para um pipeline de implantação. Em vez disso, você deve considerar o escopo de suas atribuições de função para grupos de recursos, a menos que o próprio fluxo de trabalho de implantação precise criar grupos de recursos.

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

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

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

  • Use o papel menos permissivo que puder. Se seu pipeline vai implantar apenas modelos básicos do Bicep e não gerencia atribuições de função, não use a função Proprietário.
  • Use o escopo mais restrito possível. A maioria dos pipelines só precisa implantar recursos em um grupo de recursos, portanto, eles não devem receber atribuições de função com escopo de 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 pode 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 seu site e conceder permissões apenas para o Serviço de Aplicativo e o Application Insights. No próximo mês, talvez seja necessário adicionar uma conta do Azure Cosmos DB ao seu arquivo Bicep, mas a função personalizada impedirá que os recursos do Azure Cosmos DB sejam criados. Em vez disso, geralmente é melhor usar uma função interna ou uma combinação de funções internas para evitar ter que alterar repetidamente suas definições de função. Considere usar a Política do Azure para impor seus requisitos de governança para serviços, SKUs e locais permitidos.
  • Teste o pipeline para verificar se a atribuição de função funciona.

Misturando e combinando 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.

Trabalhar com vários ambientes

Você provavelmente trabalha 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 de que ela precisa para suas implantações. Tenha especial cuidado para evitar misturar permissões para implantações de produção com aquelas para implantações em ambientes que não sejam de produção.

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

Para criar uma atribuição de função para uma entidade de serviço, use o az role assignment create comando. Você precisa especificar o cessioná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."

Vejamos cada argumento:

  • --assignee Especifica a entidade de serviço. Para evitar ambiguidades, é uma boa prática usar o 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 de função completa.
  • --scope especifica o escopo. Normalmente, trata-se de um ID de recurso para um único recurso, um grupo de recursos ou uma subscrição.
  • --description é uma descrição legível por humanos da atribuição da função.

Para criar uma atribuição de função para uma entidade de serviço, use o New-AzRoleAssignment cmdlet. Você precisa especificar o cessioná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."

Vejamos 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 você usar uma definição de função personalizada, especifique a ID de definição de função completa usando o -RoleDefinitionId argumento.
  • -Scope especifica o escopo. Normalmente, trata-se de um ID de recurso para um único recurso, um grupo de recursos ou uma subscrição.
  • -Description é uma descrição legível por humanos da atribuição da função.

Gorjeta

É uma boa prática fornecer uma justificativa para suas atribuições de função especificando uma descrição. Uma descrição ajuda qualquer pessoa que analise as atribuições de função posteriormente a entender seu propósito e como você decidiu sobre o cessionário, a função e o escopo.

Nota

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 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 o 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 o Bicep. Você pode fazer isso se inicializar seus grupos de recursos usando o Bíceps 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.'
  }
}

Vejamos cada argumento:

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