Implantar e configurar a Identidade da Carga de Trabalho em um AKS habilitado pelo cluster do Azure Arc (visualização)

Artigo
12/18/2024

Aplica-se a: Azure Local, versão 23H2

A federação de identidades de carga de trabalho permite configurar uma identidade gerenciada atribuída pelo usuário ou um registro de aplicativo no Microsoft Entra ID para confiar em tokens de um provedor de identidade externo (IdP), como o Kubernetes, permitindo o acesso a recursos protegidos pelo Microsoft Entra, como o Azure Key Vault ou o armazenamento de Blob do Azure.

O Serviço Kubernetes do Azure (AKS) habilitado pelo Azure Arc é um serviço Kubernetes gerenciado que permite implantar facilmente clusters Kubernetes habilitados para identidade de carga de trabalho. Este artigo descreve como executar as seguintes tarefas:

Crie um cluster AKS Arc com a identidade da carga de trabalho ativada (visualização).
Crie uma conta de serviço do Kubernetes e associe-a à Identidade Gerenciada do Azure.
Crie uma credencial federada na identidade gerenciada para confiar no emissor do OIDC.
Implante seu aplicativo.
Exemplo: conceda a um pod no cluster acesso a segredos em um cofre de chaves do Azure.

Para obter uma visão geral conceitual da federação de identidades de carga de trabalho, consulte Federação de identidades de carga de trabalho no Kubernetes habilitado para Arco do Azure (visualização).

Importante

Esses recursos de visualização estão disponíveis em uma base de autoatendimento e aceitação. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. O Serviço Kubernetes do Azure, habilitado pelas visualizações do Azure Arc, é parcialmente coberto pelo suporte ao cliente com base no melhor esforço.

Nota

Na pré-visualização pública, o AKS no Azure Local, versão 23H2, suporta a ativação da identidade da carga de trabalho durante a criação do cluster AKS. No entanto, não há suporte para habilitar a identidade da carga de trabalho após a criação do cluster ou desativá-la depois.

Pré-requisitos

Antes de implantar um cluster Kubernetes com o Azure Arc habilitado, você deve ter os seguintes pré-requisitos:

Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Este artigo requer a versão 1.4.23 ou posterior da CLI do Azure. Se você estiver usando o Azure Cloud Shell, a versão mais recente já está instalada.

Exportar variáveis de ambiente

Para ajudar a simplificar as etapas para configurar as identidades necessárias, os comandos a seguir definem variáveis de ambiente que são referenciadas nos exemplos deste artigo. Substitua os seguintes valores pelos seus:

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Definir a subscrição ativa

Primeiro, defina sua assinatura como a assinatura ativa atual. Execute o comando az account set com seu ID de assinatura:

az login  
az account set -s $AZSubscriptionID

Criar um grupo de recursos

Um grupo de recursos do Azure é um grupo lógico no qual os recursos do Azure são implantados e gerenciados. Ao criar um grupo de recursos, você será solicitado a especificar um local. Esse local é o local de armazenamento dos metadados do grupo de recursos e onde os recursos são executados no Azure se você não especificar outra região durante a criação do recurso.

Para criar um grupo de recursos, execute o comando az group create:

az group create --name $resource_group_name --location $Location

A saída de exemplo a seguir mostra a criação bem-sucedida de um grupo de recursos:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Etapa 1: Criar um cluster AKS Arc com a identidade da carga de trabalho habilitada

Para criar um cluster AKS Arc, você precisa dos $customlocation_ID valores e $logicnet_Id .

$customlocation_ID: A ID do Azure Resource Manager do local personalizado. O local personalizado é configurado durante a implantação do cluster Azure Local, versão 23H2. O administrador da infraestrutura deve fornecer a ID do Gerenciador de Recursos do local personalizado. Você também pode obter a ID do Gerenciador de Recursos usando $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv), se o administrador de infraestrutura fornecer um nome de local personalizado e um nome de grupo de recursos.
$logicnet_Id: A ID do Azure Resource Manager da rede lógica local do Azure criada seguindo estas etapas. O administrador da infraestrutura deve fornecer a ID do Gerenciador de Recursos da rede lógica. Você também pode obter a ID do Gerenciador de Recursos usando $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv), se o administrador de infraestrutura fornecer um nome de rede lógico e um nome de grupo de recursos.

Execute o comando az aksarc create com o --enable-oidc-issuer --enable-workload-identity parâmetro. Forneça seus entra-admin-group-object-ids e certifique-se de que você é membro do grupo de administração do Microsoft Entra ID para acesso ao modo proxy:

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

Após alguns minutos, o comando conclui e retorna informações formatadas em JSON sobre o cluster.

Pode levar algum tempo para que a extensão de identidade da carga de trabalho seja implantada após a criação bem-sucedida de um cluster provisionado. Use o seguinte comando para verificar o status da extensão de identidade da carga de trabalho:

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 

"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/"}

No portal do Azure, você pode exibir a extensão wiextension na seção Propriedades do cluster do Kubernetes.

Importante

Como parte do aprimoramento de segurança para clusters AKS Arc, a ativação da identidade da carga de trabalho aciona duas alterações. Primeiro, a chave de assinatura da conta de serviço do Kubernetes gira automaticamente a cada 45 dias e permanece válida por 90 dias. Em segundo lugar, a bandeira é desativada, reduzindo a --service-account-extend-token-expiration validade do token de um ano para um máximo de 24 horas.

Salvar a URL do emissor OIDC em uma variável de ambiente

Uma vez que o cluster AKS é criado com sucesso, você pode obter o URL do emissor OIDC e salvá-lo em uma variável de ambiente. Execute o seguinte comando:

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

Etapa 2: Criar uma conta de serviço do Kubernetes e vinculá-la à Identidade Gerenciada do Azure

Primeiro, crie uma identidade gerenciada. Execute o comando az identity create :

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

Em seguida, crie variáveis para o ID do cliente da identidade gerenciada:

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

Criar uma conta de serviço do Kubernetes

Crie uma conta de serviço Kubernetes e anote-a com o ID do cliente da identidade gerenciada criada na etapa anterior:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Abra uma nova janela. Copie e cole os seguintes comandos da CLI:

$yaml = @" apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: $MSIId name: $SERVICE_ACCOUNT_NAME namespace: $SERVICE_ACCOUNT_NAMESPACE "@ $yaml = $yaml -replace '\$MSIId', $MSIId ` -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE $yaml | kubectl apply -f -

A saída a seguir mostra a criação bem-sucedida da conta de serviço:

serviceaccount/workload-identity-sa created

Etapa 3: Criar uma credencial federada na identidade gerenciada para confiar no emissor do OIDC

Primeiro, crie uma credencial de identidade federada. Chame 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. Para obter mais informações sobre credenciais de identidade federada no Microsoft Entra, consulte Visão geral das credenciais de identidade federada no Microsoft Entra ID.

# Create a federated credential 

az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 

az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Nota

Depois de adicionar uma credencial de identidade federada, leva alguns segundos para se propagar. As solicitações de token feitas imediatamente depois podem falhar até que o cache seja atualizado. Para evitar esse problema, considere adicionar um breve atraso após a criação da credencial de identidade federada.

Etapa 4: Implantar seu aplicativo

Quando você implanta seus pods de aplicativo, o manifesto deve fazer referência à conta de serviço criada na etapa Criar conta de serviço do Kubernetes. O manifesto a seguir mostra como fazer referência à conta, especificamente as metadata\namespace propriedades e spec\serviceAccountName . Certifique-se de especificar uma imagem para image e um nome de contêiner para containerName:

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f -

Importante

Certifique-se de que os pods de aplicativo que usam a identidade de carga de trabalho incluam o rótulo azure.workload.identity/use: "true" na especificação do pod. Caso contrário, os pods falham depois de serem reiniciados.

Exemplo: Conceder permissões para acessar o Cofre da Chave do Azure

As instruções nesta etapa descrevem como acessar segredos, chaves ou certificados em um cofre de chaves do Azure a partir do pod. Os exemplos nesta seção configuram o acesso a segredos no cofre de chaves para a identidade da carga de trabalho, mas você pode executar etapas semelhantes para configurar o acesso a chaves ou certificados.

O exemplo a seguir mostra como usar o modelo de permissão de controle de acesso baseado em função do Azure (Azure RBAC) para conceder acesso ao pod ao cofre de chaves. Para obter mais informações sobre o modelo de permissão do Azure RBAC para o Azure Key Vault, consulte Conceder permissão a aplicativos para acessar um cofre de chaves do Azure usando o Azure RBAC.

Crie um cofre de chaves com proteção contra limpeza e autorização RBAC habilitada. Você também pode usar um cofre de chaves existente se ele estiver configurado para proteção contra limpeza e autorização RBAC:

az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization

# retrieve the key vault ID for role assignment
$KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)

Atribua a função de Oficial de Segredos do Cofre de Chaves RBAC a si mesmo para que você possa criar um segredo no novo cofre de chaves. Novas atribuições de função podem levar até cinco minutos para serem propagadas e atualizadas pelo servidor de autorização.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

Crie um segredo no cofre de chaves:

az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"

Atribua a função Usuário de Segredos do Cofre de Chaves à identidade gerenciada atribuída pelo usuário que você criou anteriormente. Esta etapa dá à identidade gerenciada permissão para ler segredos do cofre de chaves:
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

Crie uma variável de ambiente para o URL do cofre de chaves:

$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)

Implante um pod que faça referência à conta de serviço e ao URL do cofre de chaves:

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: ghcr.io/azure/azure-workload-identity/msal-go 
      name: oidc 
      env: 
      - name: KEYVAULT_URL 
        value: $KVUrl 
      - name: SECRET_NAME 
        value: $KVSecretName 
  nodeSelector: 
    kubernetes.io/os: linux 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                -replace '\$KVUrl', $KVUrl ` 
                -replace '\$KVSecretName', $KVSecretName 

# Apply the YAML configuration 
$yaml | kubectl --kubeconfig <path-to-aks-cluster-kubeconfig> apply -f -

Eliminar cluster do AKS Arc

Para eliminar o cluster AKS Arc, use o comando az aksarc delete:

az aksarc delete -n $aks_cluster_name -g $resource_group_name

Nota

Há um problema conhecido ao eliminar um cluster AKS Arc com os recursos PodDisruptionBudget (PDB): a eliminação pode não conseguir remover os recursos do PDB. A Microsoft está ciente do problema e está trabalhando em uma correção.

PDB é instalado por padrão em clusters AKS Arc com identidade de carga de trabalho habilitada. Para excluir um cluster AKS Arc habilitado para identidade de carga de trabalho, consulte o guia de solução de problemas .

Próximos passos

Neste artigo, você implantou um cluster Kubernetes e o configurou para usar uma identidade de carga de trabalho em preparação para cargas de trabalho de aplicativo para autenticação com essa credencial. Agora você está pronto para implantar seu aplicativo e configurá-lo para usar a identidade da carga de trabalho com a versão mais recente da biblioteca de cliente do Azure Identity.

Partilhar via

Implantar e configurar a Identidade da Carga de Trabalho em um AKS habilitado pelo cluster do Azure Arc (visualização)

Pré-requisitos

Exportar variáveis de ambiente

Definir a subscrição ativa

Criar um grupo de recursos

Etapa 1: Criar um cluster AKS Arc com a identidade da carga de trabalho habilitada

Salvar a URL do emissor OIDC em uma variável de ambiente

Etapa 2: Criar uma conta de serviço do Kubernetes e vinculá-la à Identidade Gerenciada do Azure

Criar uma conta de serviço do Kubernetes

Etapa 3: Criar uma credencial federada na identidade gerenciada para confiar no emissor do OIDC

Etapa 4: Implantar seu aplicativo

Exemplo: Conceder permissões para acessar o Cofre da Chave do Azure

Eliminar cluster do AKS Arc

Próximos passos

Comentários

Recursos adicionais