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 em seu ambiente do Azure, assim como um usuário não pode trabalhar com seus recursos do Azure, a menos que esteja autorizado a fazê-lo. Nesta unidade, você aprenderá como autorizar identidades de carga de trabalho para implantar e configurar recursos do Azure, evitando conceder permissões desnecessárias.

Autorização de identidade da carga de trabalho

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

Depois que o Microsoft Entra ID autenticar uma identidade de carga de trabalho, a próxima pergunta se torna: o que essa identidade de carga de trabalho 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 acesso a uma identidade de carga de trabalho 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 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 de diretório. Use essas funções para conceder permissões para identidades de carga de trabalho 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 é usado para ambas as situações em alguma documentação.

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

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 qual recurso ou recursos a atribuição de função se aplica (o escopo).

Cessionário

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

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

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

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

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

Role

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

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

Atenção

Conceda às identidades de carga de trabalho apenas as permissões mínimas de que precisam 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.

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. 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 identidade da 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 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 fluxos de trabalho 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 fluxo de trabalho 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 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 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 o seu fluxo de trabalho só vai implantar arquivos básicos do Bíceps 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 fluxos de trabalho 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 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 seu fluxo de trabalho 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 fluxo de trabalho 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 fluxo de trabalho 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 identidade de carga de trabalho a função de Leitor com um escopo de toda a assinatura. Você pode atribuir separadamente a mesma identidade de carga de trabalho à função de Colaborador para um grupo de recursos específico. Quando a identidade da carga de trabalho 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 identidades de carga de trabalho separadas para cada ambiente. Conceda a cada identidade de carga de trabalho 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 permissões para implantações em ambientes que não sejam de 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 az role assignment create comando. Você precisa especificar o cessioná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."

Vejamos 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 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 identidade de carga de trabalho, use o New-AzRoleAssignment cmdlet. Especifique o cessioná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."

Vejamos cada argumento:

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

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 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.'
  }
}

Vejamos cada argumento:

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