Migrar da identidade gerida do pod para a identidade da carga de trabalho

Este artigo foca-se na migração de uma identidade gerida por pod para o Microsoft Entra Workload ID no seu cluster do Azure Kubernetes Service (AKS). Também fornece orientações dependendo da versão da biblioteca cliente Azure Identity usada pela sua aplicação baseada em contentores.

Se você não estiver familiarizado com o ID de carga de trabalho do Microsoft Entra, consulte o seguinte artigo Visão geral .

Antes de começar

O Azure CLI versão 2.47.0 ou posterior. Execute az --version para localizar a versão e execute az upgrade para atualizar a versão. Se precisar de instalar ou atualizar, consulte Install Azure CLI.

Cenários de migração

Esta secção explica as opções de migração disponíveis dependendo da versão do Azure Identity SDK instalada.

Em qualquer dos cenários, você precisa ter a confiança federada configurada antes de atualizar a sua aplicação para usar a identidade da workload. Seguem-se os passos mínimos exigidos:

• Crie uma credencial de identidade gerida .
• Associe a identidade gerida à conta de serviço Kubernetes já usada para a identidade gerida pelo pod ou crie uma nova conta de serviço Kubernetes e depois associe-a à identidade gerida.
• Estabelecer uma relação de confiança federada entre a identidade gerida e o Microsoft Entra ID.

Migrar a partir da versão mais recente

Se a sua aplicação já estiver a usar a versão mais recente do Azure Identity SDK, execute os seguintes passos para completar a configuração de autenticação:

• Implementar a identidade da carga de trabalho em paralelo com a identidade gerida pelo pod. Pode reiniciar a implementação da sua aplicação para começar a usar a identidade da carga de trabalho, onde esta injeta automaticamente as anotações OIDC na aplicação.
• Depois de verificar se a aplicação consegue autenticar-se com sucesso, pode remover as anotações de identidade geridas pelo pod da sua aplicação e depois remover o add-on de identidade gerido pelo pod.

Migrar a partir de uma versão anterior

Se a sua aplicação não estiver a usar a versão mais recente do Azure Identity SDK, tem duas opções:

• Pode utilizar um sidecar de migração que fornecemos nas suas aplicações Linux, o qual encaminha as transações IMDS que a sua aplicação realiza para o OpenID Connect (OIDC). O sidecar de migração não pretende ser uma solução a longo prazo, mas sim uma forma de começar rapidamente a funcionar com a identidade da carga de trabalho. Execute as seguintes etapas para:

  • Implementa a carga de trabalho com o sidecar de migração para proxy das transações IMDS da aplicação.
  • Verifique se as transações de autenticação estão a ser concluídas com sucesso.
  • Agende o trabalho para as aplicações atualizarem os seus SDKs para uma versão suportada.
  • Depois de os SDKs serem atualizados para a versão suportada, podes remover o sidecar proxy e voltar a implementar a aplicação.

  Note

  O sidecar de migração não é suportado para utilização em produção. Esta funcionalidade destina-se a dar-lhe tempo para migrar os SDKs da sua aplicação para uma versão suportada, e não pretende ser uma solução a longo prazo. O sidecar de migração está disponível apenas para contentores Linux, devido a disponibilizar apenas identidades geridas por pod com pools de nós Linux.

• Reescreva a sua aplicação para suportar a versão mais recente da biblioteca cliente Azure Identity . Depois, execute os seguintes passos:

  • Reinicie a implementação da sua aplicação para começar a autenticação usando a identidade da carga de trabalho.
  • Depois de verificar que as transações de autenticação estão a ser concluídas com sucesso, pode remover as anotações de "pod-managed identity" da sua aplicação e depois remover o add-on "pod-managed identity".

Criar uma identidade gerenciada

Se não tiver uma identidade gerida criada e atribuída ao seu pod, execute os seguintes passos para criar e conceder as permissões necessárias para armazenamento, Key Vault ou quaisquer recursos com que a sua aplicação precise de autenticação no Azure.

1. Usa o comando Azure CLI az-account set para definir uma subscrição específica como a subscrição ativa atual. Depois usa o comando criar identidade az para criar uma identidade gerida.

   az account set --subscription "subscriptionID"
   

   az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
   

   export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"
   

2. Conceda à identidade gerida as permissões necessárias para aceder aos recursos no Azure que necessita. Para informações sobre como fazer isto, consulte Atribuir um acesso de identidade gerida a um recurso.

3. Para obter o URL do Emissor OIDC e guardá-lo numa variável ambiental, execute o seguinte comando. Substitua os valores padrão para o nome do cluster e o nome do grupo de recursos.

   export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
   

   A variável deve conter a URL do Emissor, semelhante ao seguinte exemplo:

   https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
   

   Por defeito, o Emissor está definido para usar a URL base https://{region}.oic.prod-aks.azure.com/{uuid}, onde o valor para {region} corresponde à localização em que o cluster AKS está implantado. O valor {uuid} representa a chave OIDC.

Criar conta de serviço do Kubernetes

Se não tiver uma conta dedicada de serviço Kubernetes criada para esta aplicação, execute os seguintes passos para a criar e depois anote-a com o ID do cliente da identidade gerida criada no passo anterior. Use o comando az aks get-credentials e substitua os valores do nome do cluster e do nome do grupo de recursos.

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

Copie e cole a seguinte entrada de várias linhas na CLI do Azure.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

O resultado seguinte assemelha-se à criação bem-sucedida da identidade:

Serviceaccount/workload-identity-sa created

Estabelecer um Trust Federado de Credenciais de Identidade

Use o comando az identity federated-credential create para criar a credencial de identidade federada entre a identidade gerenciada, o emissor da conta de serviço e o assunto. Substitua os valores resourceGroupName, userAssignedIdentityName, federatedIdentityName, serviceAccountNamespace, e serviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Implementar a carga de trabalho com o sidecar de migração

Se a sua aplicação estiver a usar identidade gerida e ainda depender do IMDS para obter um token de acesso, pode usar o sidecar de migração da identidade da carga de trabalho para começar a migrar para a identidade da carga de trabalho. Este sidecar é uma solução de migração e, em aplicações a longo prazo, deverá modificar o respetivo código para usar os mais recentes Azure Identity SDKs que suportam a asserção do cliente.

Para atualizar ou implementar a carga de trabalho, adicione estas anotações de pod somente se pretender utilizar o sidecar de migração. Injetas os seguintes valores de anotação para usar o sidecar na especificação do teu pod:

• azure.workload.identity/inject-proxy-sidecar - valor é true ou false
• azure.workload.identity/proxy-sidecar-port - o valor é a porta desejada para o proxy sidecar. O valor predefinido é 8000.

Quando um pod com as anotações acima é criado, o webhook de mutação do Azure Workload Identity injeta automaticamente o init-container e o proxy sidecar na especificação do pod.

O webhook que já está em execução adiciona os seguintes excertos YAML à implantação do pod. Segue-se um exemplo da especificação do pod alterado:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Esta configuração aplica-se a qualquer configuração onde um pod esteja a ser criado. Depois de atualizar ou implementar a sua aplicação, pode verificar se o pod está em estado de execução usando o comando kubectl describe pod . Substitua o valor podName pelo nome da imagem do seu pod implementado.

kubectl describe pods podName

Para verificar se o pod está a passar transações IMDS, use o comando kubectl logs . Substitua o valor podName pelo nome da imagem do seu pod implantado:

kubectl logs podName

A saída logarítmica seguinte assemelha-se a uma comunicação bem-sucedida através do sidecar proxy. Verifique se os registos mostram que um token foi obtido com sucesso e que a operação GET foi bem-sucedida.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

Remover identidade gerida pelo pod

Depois de concluir os seus testes e a aplicação conseguir obter um token usando o sidecar proxy, pode remover o mapeamento de identidade gerenciado pelo pod Microsoft Entra do seu cluster e depois remover a identidade.

1. Execute o comando az aks pod-identity delete para remover a identidade do seu pod. Isto só deve ser feito depois de todos os pods no namespace que usam o mapeamento de identidade gerido por pods terem migrado para usar o sidecar.

   az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
   

Próximos passos

Este artigo mostrou-lhe como configurar o seu pod para autenticar usando uma identidade de carga de trabalho como opção de migração. Para mais informações sobre o Microsoft Entra ID de Carga de Trabalho, consulte o seguinte artigo de visão geral.