Conceder acesso de identidade de carga de trabalho ao Azure

  • 6 minutos

Por si só, uma identidade de carga de trabalho não pode fazer nada no seu ambiente Azure, tal como um utilizador não pode trabalhar com os seus recursos Azure, a menos que esteja autorizado a fazê-lo. Nessa unidade, você aprenderá como autorizar identidades de carga de trabalho para implantar e configurar recursos do Azure, evitando ao mesmo tempo conceder permissões desnecessárias.

Autorização de identidade de carga de trabalho

Até agora, você se concentrou em quais são as identidades de carga de trabalho e como elas podem ser usadas para provar a identidade de um fluxo de trabalho de implantação no Microsoft Entra ID. Trata-se de autenticação.

Depois que o Microsoft Entra ID autenticou uma identidade de carga de trabalho, a próxima pergunta é: o que essa identidade de carga de trabalho 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 acesso de identidade de carga de trabalho a um grupo de recursos, assinatura ou grupo de gerenciamento específico.

Observação

Tudo o que você está fazendo aqui é usar o sistema Azure RBAC para conceder acesso para criar e gerenciar recursos do Azure, como contas de armazenamento, plano de Serviço de Aplicativo do Azure e 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 identidades de carga de trabalho gerenciarem o Microsoft Entra ID. Esse módulo não discute esse assunto em profundidade, mas esteja ciente de que o termo role é usado para ambas as situações em algumas documentações.

Selecionar a atribuição de função certa para seu fluxo de trabalho

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

Atribuição

Quando você trabalha com uma identidade de carga de trabalho, atribui funções a ela. Para atribuir uma função, você precisa primeiro criar uma principal de serviço, que permite conceder funções de aplicativo no Azure. Depois de criar a entidade de serviço, você poderá continuar trabalhando com a ID do aplicativo do registro do aplicativo.

Para criar uma entidade de serviço, use o comando az ad sp create e especifique a ID do aplicativo do registro do aplicativo:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Para criar uma entidade de serviço, use o cmdlet New-AzADServicePrincipal e especifique a ID do aplicativo do registro do aplicativo:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Função

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

  • Leitor: Permite que o destinatário leia informações sobre recursos, mas não as modifique ou exclua.
  • Colaborador: 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: permite controle total sobre os recursos, incluindo a concessão de acesso a outras entidades de segurança.

Cuidado

Conceda às identidades de carga de trabalho 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 fluxo de trabalho de implantação.

Há também muitas funções específicas que fornecem acesso a um subconjunto de funcionalidades. Você pode até mesmo criar sua própria 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. 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 identidade de carga de trabalho pode modificar. Os escopos comuns incluem:

  • Recurso único: você pode conceder acesso a um recurso específico. Normalmente, os fluxos de trabalho de implantação não usam esse escopo porque um fluxo de trabalho 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 fluxos de trabalho 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 fluxo de trabalho 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.

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

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 fluxo de trabalho só vai implantar arquivos 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 fluxos de trabalho 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 fluxos de trabalho, 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 o seu fluxo de trabalho 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 fluxo de trabalho 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 fluxo de trabalho 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 identidade de carga de trabalho a função de Leitor com um escopo de toda a assinatura. Você pode atribuir separadamente à mesma identidade de carga de trabalho a função de Colaborador para um grupo de recursos específico. Quando a identidade de carga de trabalho 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 identidades de carga de trabalho separadas para cada ambiente. Conceda a cada identidade de carga de trabalho 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 uma identidade de carga de trabalho

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

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Vamos examinar cada argumento:

  • --assignee especifica a identidade da carga de trabalho. Você pode especificar isso de várias maneiras, mas usar a ID do aplicativo é uma boa prática porque evita ambiguidade.
  • --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 identidade de carga de trabalho, use o cmdlet New-AzRoleAssignment. Especifique o destinatário, a função e o escopo:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Vamos examinar cada argumento:

  • -ApplicationId especifica o ID de registro do aplicativo da identidade da carga de trabalho.
  • -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.

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ê poderá fazer isso se inicializar seus grupos de recursos usando o Bicep e, em seguida, implantar os recursos no grupo de recursos usando uma identidade de carga de trabalho. Aqui está um exemplo de definição de Bicep para a atribuição de função anterior:

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

Vamos examinar cada argumento:

  • name é um GUID (identificador global exclusivo) para a atribuição de função. É uma boa prática usar a função guid() no Bicep para criar um GUID. Para garantir que você crie um nome exclusivo para cada atribuição de função, use a ID de entidade de segurança, a ID de definição de função e o escopo como argumentos de semente para a 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ê trabalha com funções internas, portanto, é possível 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ê usa uma ID de recurso totalmente qualificado, como /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/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.