Partilhar via

Usar uma identidade gerenciada no Serviço Kubernetes do Azure (AKS)

Os clusters do Serviço Kubernetes do Azure (AKS) exigem uma identidade do Microsoft Entra para acessar recursos do Azure, como balanceadores de carga e discos gerenciados. As identidades gerenciadas para recursos do Azure são a maneira recomendada de autorizar o acesso de um cluster AKS a outros serviços do Azure.

Você pode usar uma identidade gerenciada para autorizar o acesso de um cluster AKS a qualquer serviço que ofereça suporte à autorização do Microsoft Entra, sem precisar gerenciar credenciais ou incluí-las em seu código. Você atribui à identidade gerenciada uma função de controle de acesso baseado em função do Azure (Azure RBAC) para conceder-lhe permissões para um recurso específico no Azure. Por exemplo, você pode conceder permissões a uma identidade gerenciada para acessar segredos em um cofre de chaves do Azure para uso pelo cluster. Para obter mais informações sobre o RBAC do Azure, consulte O que é o controle de acesso baseado em função do Azure (Azure RBAC)?.

Este artigo mostra como habilitar os seguintes tipos de identidade gerenciada em um cluster AKS novo ou existente:

  • Identidade gerenciada atribuída ao sistema. Uma identidade gerenciada atribuída ao sistema está associada a um único recurso do Azure, como um cluster AKS. Ele existe apenas para o ciclo de vida do cluster.
  • Identidade gerenciada atribuída pelo usuário. Uma identidade gerenciada atribuída pelo usuário é um recurso autônomo do Azure que um cluster AKS pode usar para autorizar o acesso a outros serviços do Azure. Ele persiste separadamente do cluster AKS e pode ser usado por vários recursos do Azure.
  • Identidade gerenciada kubelet pré-criada. Uma identidade gerenciada kubelet pré-criada é uma identidade opcional atribuída pelo usuário que o kubelet pode usar para acessar outros recursos no Azure. Se você não especificar uma identidade gerenciada atribuída pelo usuário para o kubelet, o AKS criará uma identidade kubelet atribuída pelo usuário no grupo de recursos do nó.

Para saber mais sobre identidades gerenciadas, consulte Identidades gerenciadas para recursos do Azure.

Visão geral

Um cluster AKS usa uma identidade gerenciada para solicitar tokens do Microsoft Entra. Esses tokens são usados para autorizar o acesso a outros recursos em execução no Azure. Você pode atribuir uma função RBAC do Azure a uma identidade gerenciada para conceder permissões de cluster para acessar recursos específicos. Por exemplo, se o cluster precisar acessar segredos em um cofre de chaves do Azure, você poderá atribuir à identidade gerenciada do cluster uma função RBAC do Azure que conceda essas permissões.

Uma identidade gerenciada pode ser atribuída ao sistema ou ao usuário. Esses dois tipos de identidades gerenciadas são semelhantes, pois você pode usar qualquer tipo para autorizar o acesso aos recursos do Azure a partir do cluster AKS. A principal diferença entre eles é que uma identidade gerenciada atribuída ao sistema está associada a um único recurso do Azure, como um cluster AKS, enquanto uma identidade gerenciada atribuída pelo usuário é ela própria um recurso autônomo do Azure. Para obter mais detalhes sobre as diferenças entre tipos de identidades gerenciadas, consulte Tipos de identidade gerenciados em Identidades gerenciadas para recursos do Azure.

Ambos os tipos de identidades geridas são geridos pela plataforma Azure, para que o utilizador possa autorizar o acesso das suas aplicações sem precisar provisionar ou rodar segredos. O Azure gerencia as credenciais da identidade para você.

Quando você implanta um cluster AKS, uma identidade gerenciada atribuída ao sistema é criada para você por padrão. Você também pode criar o cluster com uma identidade gerenciada atribuída pelo usuário.

Também é possível criar um cluster com um principal de serviço de aplicação em vez de uma identidade gerida. As identidades gerenciadas são recomendadas em relação às entidades de serviço para segurança e facilidade de uso. Para obter mais informações sobre como criar um cluster com uma entidade de serviço, consulte Usar uma entidade de serviço com o Serviço Kubernetes do Azure (AKS).

Você pode atualizar um cluster existente para usar uma identidade gerida associada a um principal de serviço de aplicativo. Você também pode atualizar um cluster existente para um tipo diferente de identidade gerenciada. Se o cluster já estiver usando uma identidade gerenciada e a identidade tiver sido alterada, por exemplo, se você atualizou o tipo de identidade do cluster de atribuído pelo sistema para atribuído pelo usuário, haverá um atraso enquanto os componentes do plano de controle mudam para a nova identidade. Os componentes do plano de controle continuam a usar a identidade antiga até que seu token expire. Depois que o token é atualizado, eles mudam para a nova identidade. Este processo pode demorar várias horas.

Os tipos de identidade atribuídos pelo sistema e pelo usuário diferem de uma identidade do Microsoft Entra Workload, que se destina ao uso por um aplicativo em execução em um pod.

Antes de começar

Antes de executar os exemplos neste artigo, defina sua assinatura como a assinatura ativa atual chamando o comando az account set e passando sua ID de assinatura.

az account set --subscription <subscription-id>

Crie também um grupo de recursos do Azure se ainda não tiver um chamando o az group create comando.

az group create \
    --name myResourceGroup \
    --location westus2

Habilitar uma identidade gerenciada atribuída ao sistema

Uma identidade gerenciada atribuída ao sistema é uma identidade associada a um cluster AKS ou outro recurso do Azure. A identidade gerenciada atribuída ao sistema está vinculada ao ciclo de vida do cluster. Quando o cluster é excluído, a identidade gerenciada atribuída ao sistema também é excluída.

O cluster AKS pode usar a identidade gerenciada atribuída ao sistema para autorizar o acesso a outros recursos em execução no Azure. Você pode atribuir uma função RBAC do Azure à identidade gerenciada atribuída pelo sistema para conceder permissões de cluster para acessar recursos específicos. Por exemplo, se o cluster precisar acessar segredos em um cofre de chaves do Azure, você poderá atribuir à identidade gerenciada atribuída ao sistema uma função RBAC do Azure que conceda essas permissões.

Habilitar uma identidade gerenciada atribuída ao sistema em um novo cluster AKS

Para habilitar uma identidade gerida atribuída pelo sistema em um novo cluster, chame o az aks create. Uma identidade gerenciada atribuída ao sistema é habilitada no novo cluster por padrão.

Crie um cluster AKS usando o comando az aks create.

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --generate-ssh-keys

Para verificar se uma identidade gerenciada atribuída ao sistema está habilitada para o cluster depois de criado, consulte Determinar que tipo de identidade gerenciada um cluster está usando.

Atualizar um cluster AKS existente para usar uma identidade gerenciada atribuída ao sistema

Para atualizar um cluster AKS existente que esteja usando um principal de serviço para usar uma identidade gerida atribuída pelo sistema, execute o comando az aks update com o parâmetro --enable-managed-identity.

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity

Depois de atualizar o cluster para usar uma identidade gerenciada atribuída pelo sistema em vez de uma entidade de serviço, o plano de controle e os pods usam a identidade gerenciada atribuída pelo sistema para autorização ao acessar outros serviços no Azure. O Kubelet continua usando uma entidade de serviço até que você também atualize seu agentpool. Você pode usar o comando az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only nos seus nós para atualizar para uma identidade suportada. Uma atualização do pool de nós causa tempo de inatividade para o cluster AKS à medida que os nós nos pools de nós são isolados, drenados e recriados.

Observação

Lembre-se das seguintes informações ao atualizar o cluster:

  • Uma atualização só funciona se houver uma atualização VHD para consumir. Se você estiver executando o VHD mais recente, precisará esperar até que o próximo VHD esteja disponível para executar a atualização.

  • A CLI do Azure garante que a permissão do seu addon seja definida corretamente após a migração. Se você não estiver usando a CLI do Azure para executar a operação de migração, precisará manipular a permissão da identidade do complemento sozinho. Para obter um exemplo usando um modelo do Azure Resource Manager (ARM), consulte Atribuir funções do Azure usando modelos ARM.

  • Se o cluster estava usando --attach-acr para extrair imagens do Registro de Contêiner do Azure (ACR), você precisará executar o az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID> comando depois de atualizar o cluster para permitir que o kubelet recém-criado usado para identidade gerenciada obtenha a permissão para extrair do ACR. Caso contrário, você não poderá extrair do ACR após a atualização.

Adicionar uma atribuição de função para uma identidade gerenciada atribuída ao sistema

Você pode atribuir uma função RBAC do Azure à identidade gerenciada atribuída ao sistema para conceder as permissões de cluster em outro recurso do Azure. O RBAC do Azure dá suporte a definições de função internas e personalizadas que especificam níveis de permissões. Para obter mais informações sobre como atribuir funções RBAC do Azure, consulte Etapas para atribuir uma função do Azure.

Ao atribuir uma função RBAC do Azure a uma identidade gerenciada, você deve definir o escopo da função. Em geral, é uma prática recomendada limitar o escopo de uma função aos privilégios mínimos exigidos pela identidade gerenciada. Para obter mais informações sobre como definir o escopo das funções do RBAC do Azure, consulte Entender o escopo do RBAC do Azure.

Quando você cria e usa sua própria rede virtual, discos do Azure anexados, endereço IP estático, tabela de rotas ou identidade kubelet atribuída pelo usuário onde os recursos estão fora do grupo de recursos do nó de trabalho, a CLI do Azure adiciona a atribuição de função automaticamente. Se você estiver usando um modelo ARM ou outro método, use a ID principal da identidade gerenciada para executar uma atribuição de função.

Se você não estiver usando a CLI do Azure, mas estiver usando sua própria rede virtual, discos do Azure anexados, endereço IP estático, tabela de rotas ou identidade kubelet atribuída pelo usuário que esteja fora do grupo de recursos do nó de trabalho, recomendamos usar uma identidade gerenciada atribuída pelo usuário para o plano de controle. Quando o plano de controle usa uma identidade gerenciada atribuída ao sistema, a identidade é criada ao mesmo tempo que o cluster, portanto, a atribuição de função não pode ser executada até que o cluster tenha sido criado.

Obter a ID principal da identidade gerenciada atribuída ao sistema

Para atribuir uma função RBAC do Azure à identidade gerenciada atribuída ao sistema de um cluster, primeiro você precisa da ID principal da identidade gerenciada. Obtenha a ID principal para a identidade gerenciada atribuída ao sistema do cluster chamando o az aks show comando.

# Get the principal ID for a system-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.principalId \
    --output tsv)

Atribuir uma função RBAC do Azure à identidade gerenciada atribuída ao sistema

Para conceder permissões de identidade gerenciada atribuídas pelo sistema a um recurso no Azure, chame o az role assignment create comando para atribuir uma função RBAC do Azure à identidade gerenciada.

Para uma VNet, disco do Azure anexado, endereço IP estático ou tabela de rotas fora do grupo de recursos padrão do nó de trabalho, precisa-se atribuir a função Network Contributor no grupo de recursos personalizado.

Por exemplo, atribua a Network Contributor função no grupo de recursos personalizado usando o az role assignment create comando. Para o parâmetro --scope, forneça a ID do recurso do grupo de recursos do cluster.

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Network Contributor" \
    --scope "<resource-group-id>"

Observação

Pode levar até 60 minutos para que as permissões concedidas à identidade gerenciada do cluster se propaguem.

Habilitar uma identidade gerenciada atribuída pelo usuário

Uma identidade gerenciada atribuída pelo usuário é um recurso autônomo do Azure. Quando você cria um cluster com uma identidade gerenciada atribuída pelo usuário para o plano de controle, o recurso de identidade gerenciada atribuído pelo usuário deve existir antes da criação do cluster. Esse recurso permite cenários como a criação do cluster com uma VNet personalizada ou com um tipo de saída de UDR (roteamento definido pelo usuário).

Criar uma identidade gerenciada atribuída pelo usuário

Se você ainda não tiver um recurso de identidade gerenciado atribuído pelo usuário, crie um usando o az identity create comando.

az identity create \
    --name myIdentity \
    --resource-group myResourceGroup

Sua saída deve ser semelhante à saída de exemplo a seguir:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Obter o ID principal da identidade gerenciada atribuída pelo usuário

Para obter o ID principal da identidade gerenciada atribuída pelo usuário, chame az identity show e consulte a principalId propriedade:

CLIENT_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query principalId \
    --output tsv)

Obter o ID de recurso da identidade gerenciada atribuída pelo usuário

Para criar um cluster com uma identidade gerenciada atribuída pelo usuário, você precisará da ID do recurso para a nova identidade gerenciada. Para obter o ID de recurso da identidade gerida atribuída pelo utilizador, utilize o comando az aks show para consultar a propriedade id.

RESOURCE_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query id \
    --output tsv)

Atribuir uma função RBAC do Azure à identidade gerenciada atribuída pelo usuário

Antes de criar o cluster, adicione uma atribuição de função para a identidade gerenciada chamando o az role assignment create comando.

O exemplo a seguir atribui a função Usuário de Segredos do Cofre de Chaves à identidade gerenciada atribuída pelo usuário para conceder-lhe permissões para acessar segredos em um cofre de chaves. A atribuição de função tem como escopo o recurso do cofre de chaves:

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Key Vault Secrets User" \
    --scope "<keyvault-resource-id>"

Observação

Pode levar até 60 minutos para que as permissões concedidas à identidade gerenciada do cluster se propaguem.

Criar um cluster com a identidade gerenciada atribuída pelo usuário

Para criar um cluster AKS com a identidade gerenciada atribuída pelo usuário, chame o az aks create comando. Inclua o --assign-identity parâmetro e passe o ID do recurso para a identidade gerenciada atribuída pelo usuário:

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --assign-identity $RESOURCE_ID \
    --generate-ssh-keys

Observação

As regiões USDOD Central, USDOD East e USGov Iowa na nuvem do Azure US Government não suportam a criação de um cluster com uma identidade gerenciada atribuída pelo usuário.

Atualizar um cluster existente para usar uma identidade gerenciada atribuída pelo usuário

Para atualizar um cluster existente para usar uma identidade gerenciada atribuída pelo usuário, chame o az aks update comando. Inclua o --assign-identity parâmetro e passe o ID do recurso para a identidade gerenciada atribuída pelo usuário:

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity $RESOURCE_ID

A saída para uma atualização de cluster bem-sucedida para usar uma identidade gerenciada atribuída pelo usuário deve ser semelhante à saída de exemplo a seguir:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },

Observação

A migração de uma identidade gerenciada para o plano de controle de atribuído pelo sistema para atribuído pelo usuário não resulta em nenhum tempo de inatividade para o plano de controle e os pools de agentes. Os componentes do plano de controle mantêm a antiga identidade atribuída pelo sistema por até várias horas, até à próxima renovação do token.

Determinar que tipo de identidade gerenciada um cluster está usando

Para determinar que tipo de identidade gerenciada seu cluster AKS existente está usando, chame o comando az aks show e consulte a propriedade type da identidade.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.type \
    --output tsv

Se o cluster estiver usando uma identidade gerenciada, o valor da propriedade type será SystemAssigned ou UserAssigned.

Se o cluster estiver usando uma entidade de serviço, o valor da propriedade type será null. Considere atualizar seu cluster para usar uma identidade gerenciada.

Use uma identidade precriada gerida pelo kubelet

Uma identidade kubelet pré-criada é uma identidade gerenciada atribuída pelo usuário que existe antes da criação do cluster. Esse recurso habilita cenários como a conexão com o Registro de Contêiner do Azure (ACR) durante a criação do cluster.

Observação

O AKS cria uma identidade kubelet atribuída pelo usuário no grupo de recursos do nó se você não especificar sua própria identidade gerenciada pelo kubelet.

Para uma identidade kubelet atribuída pelo utilizador fora do grupo de recursos do nó trabalhador padrão, é necessário atribuir a função de Operador de Identidade Gerenciada à identidade kubelet para o plano de controle da identidade gerenciada.

identidade gerenciada kubelet

Se você não tiver uma identidade gerenciada pelo kubelet, crie uma usando o az identity create comando.

az identity create \
    --name myKubeletIdentity \
    --resource-group myResourceGroup

Sua saída deve ser semelhante à saída de exemplo a seguir:

{
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", 
  "location": "westus2",
  "name": "myKubeletIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Atribuir uma função RBAC à identidade gerenciada pelo kubelet

Atribua a função ACRPull à identidade kubelet usando o comando az role assignment create. Forneça a ID principal da identidade kubelet para a variável $KUBELET_CLIENT_ID e forneça a ID do Registro ACR para a variável $ACR_REGISTRY_ID.

az role assignment create \
    --assignee $KUBELET_CLIENT_ID \
    --role "acrpull" \
    --scope "$ACR_REGISTRY_ID"

Crie um cluster para utilizar a identidade do kubelet.

Agora você pode criar seu cluster AKS com suas identidades existentes. Certifique-se de fornecer o ID de recurso da identidade gerida para o plano de controlo, incluindo o argumento assign-identity, e a identidade gerida do kubelet usando o argumento assign-kubelet-identity.

Crie um cluster AKS com suas identidades existentes usando o az aks create comando.

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Uma criação bem-sucedida de cluster AKS usando uma identidade gerenciada kubelet deve resultar em uma saída semelhante à seguinte:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "<client-id>",
      "objectId": "<object-id>",
      "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
    }
  },

Atualizar um cluster existente para usar a identidade kubelet

Para atualizar um cluster existente para usar a identidade gerenciada kubelet, primeiro obtenha a identidade gerenciada do plano de controle atual para seu cluster AKS.

Advertência

Atualizar a identidade gerida do kubelet atualiza os pools de nós do cluster AKS, certifique-se de ter configuradas as opções de disponibilidade corretas, como Orçamentos de Interrupção de Pods, antes de o executar, para evitar a interrupção da carga de trabalho, ou realize a atualização durante uma janela de manutenção.

  1. Confirme se o cluster AKS está usando a identidade gerenciada atribuída pelo usuário usando o az aks show comando.

    az aks show \
    --resource-group <RGName> \
    --name <ClusterName> \
    --query "servicePrincipalProfile"

    Se o cluster estiver usando uma identidade gerenciada, a saída será exibida clientId com um valor msi. Um cluster utilizando um principal de serviço exibe um identificador de objeto. Por exemplo:

    # The cluster is using a managed identity.
{
  "clientId": "msi"
}

  2. Depois de confirmar que o cluster está usando uma identidade gerenciada, localize o ID de recurso da identidade gerenciada usando o az aks show comando.

    az aks show --resource-group <RGName> \
    --name <ClusterName> \
    --query "identity"

    Para uma identidade gerenciada atribuída pelo usuário, sua saída deve ser semelhante à saída de exemplo a seguir:

    {
  "principalId": null,
  "tenantId": null,
  "type": "UserAssigned",
  "userAssignedIdentities": <identity-resource-id>
      "clientId": "<client-id>",
      "principalId": "<principal-id>"
},

  3. Atualize seu cluster com suas identidades existentes usando o az aks update comando. Forneça a ID de recurso da identidade gerenciada atribuída pelo usuário para o plano de controle para o assign-identity argumento. Forneça o ID do recurso da identidade gerenciada do kubelet para o assign-kubelet-identity argumento.

    az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id>

Sua saída para uma atualização de cluster bem-sucedida usando sua própria identidade gerenciada kubelet deve ser semelhante à saída de exemplo a seguir:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "<client-id>",
      "objectId": "<object-id>",
      "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
    }
  },

Observação

Se o cluster estava a usar --attach-acr para extrair imagens do Registro de Contêiner do Azure, execute o comando az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> depois de atualizar o cluster para que o kubelet recém-criado, que utiliza identidade gerida, obtenha permissão para extrair do ACR. Caso contrário, você não poderá extrair do ACR após a atualização.

Obter as propriedades da identidade kubelet

Para obter as propriedades da identidade de kubelet, chame az aks show e consulte a propriedade identityProfile.kubeletidentity.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query "identityProfile.kubeletidentity"

Limitações de identidade kubelet pré-configuradas

Observe as seguintes limitações para a identidade kubelet pré-criada:

  • Uma identidade kubelet pré-criada deve ser uma identidade gerenciada atribuída pelo usuário.
  • As regiões Leste da China e Norte da China no Microsoft Azure operadas pela 21Vianet não são suportadas.

Resumo das identidades gerenciadas usadas pelo AKS

O AKS usa várias identidades gerenciadas para serviços e complementos integrados.

Identidade Nome Caso de uso Permissões padrão Traga a sua própria identidade
Plano de controlo Nome do cluster AKS Usado por componentes do plano de controlo do AKS para gerir recursos do cluster, incluindo balanceadores de carga de ingressos e IPs públicos geridos pelo AKS, Autoescalador de Cluster, Disco do Azure, Ficheiro, e drivers CSI de Blob. Função de colaborador para o grupo de recursos Node Suportado
Kubelet Nome do Cluster AKS-agentpool Autenticação com o Azure Container Registry (ACR). N/A (para kubernetes v1.15+) Suportado
Suplemento AzureNPM Não é necessária identidade. N/A Não
Suplemento Monitoramento de rede AzureCNI Não é necessária identidade. N/A Não
Suplemento azure-policy (gatekeeper) Não é necessária identidade. N/A Não
Suplemento política do Azure Não é necessária identidade. N/A Não
Suplemento Calico Não é necessária identidade. N/A Não
Suplemento roteamento de aplicativos Gerencia o DNS do Azure e os certificados do Azure Key Vault Segredos do Cofre da Chave Função de utilizador para o Cofre da Chave, função de Colaborador da Zona DNZ para zonas DNS, função de Colaborador da Zona DNS Privada para zonas DNS privadas Não
Suplemento HTTPApplicationRouting Gerencia os recursos de rede necessários. Função de leitor para o grupo de recursos do nó, função de colaborador para a zona DNS. Não
Suplemento Gateway de aplicativo de ingresso Gerencia os recursos de rede necessários. Função de colaborador para o grupo de recursos do nó Não
Suplemento omsagent Usado para enviar métricas AKS para o Azure Monitor. Função de Publicador de Métricas de Monitoramento Não
Suplemento Virtual-Node (ACIConnector) Gerencia os recursos de rede necessários para as Instâncias de Contêiner do Azure (ACI). Função de colaborador para o grupo de recursos do nó Não
Suplemento Análise de custos Usado para coletar dados de alocação de custos
Identidade da carga de trabalho ID de carga de trabalho do Microsoft Entra Permite que os aplicativos acessem recursos de nuvem com segurança com o ID de carga de trabalho do Microsoft Entra. N/A Não

Importante

A identidade gerenciada por pod de código aberto Microsoft Entra (visualização) no Serviço Kubernetes do Azure foi descontinuada em 24/10/2022, e o projeto arquivado em setembro de 2023. Para obter mais informações, consulte o aviso de descontinuação. O complemento AKS Managed começa a ser descontinuado em setembro de 2024.

Recomendamos que você revise o ID da carga de trabalho do Microsoft Entra. A autenticação Entra Workload ID substitui a funcionalidade de identidade gerida por pod, agora preterida (pré-visualização). A ID de Carga de Trabalho do Entra é o método recomendado para permitir que um aplicativo em execução em um pod se autentique em outros serviços do Azure que oferecem suporte a ele.

Limitações

  • Não há suporte para mover ou migrar um cluster gerenciado habilitado para identidade para um locatário diferente.

  • Se o cluster tiver a identidade gerida pelo pod do Microsoft Entra (aad-pod-identity) ativada, os pods de Identidade Node-Managed (NMI) modificarão os iptables dos nós para interceptar chamadas para o ponto de extremidade IMDS (Metadados de Instância do Azure). Essa configuração significa que qualquer solicitação feita ao endpoint IMDS é intercetada pelo NMI, mesmo que um pod específico não use aad-pod-identity.

    A definição de recurso personalizada (CRD) AzurePodIdentityException pode ser configurada para especificar que as solicitações para o ponto de extremidade IMDS originadas de um pod com rótulos correspondentes definidos no CRD devem ser encaminhadas por proxy sem qualquer processamento no NMI. Exclua os pods do sistema com o rótulo kubernetes.azure.com/managedby: aks no namespace kube-system ao configurar o CRD AzurePodIdentityException aad-pod-identity. Para obter mais informações, consulte Usar identidades geridas por pod do Microsoft Entra no Serviço de Kubernetes do Azure.

    Para configurar uma exceção, instale o mic-exception YAML.

  • O AKS não suporta o uso de uma identidade gerenciada atribuída ao sistema ao usar uma zona DNS privada personalizada.

Próximos passos