Implantar e configurar o Workload Identity em um AKS habilitado pelo cluster do Azure Arc (versão preliminar)

Aplica-se a: AKS no Azure Local

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

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

• Crie um cluster do AKS Arc com a identidade de workload habilitada (versão preliminar).
• Crie uma conta de serviço do Kubernetes e vincule-a à Identidade gerenciada do Azure.
• Crie uma credencial federada na identidade gerenciada para estabelecer confiança com o emissor do OIDC.
• Implante seu aplicativo.
• Exemplo: conceda a um pod no acesso ao cluster a segredos em um cofre de chaves do Azure.

Para obter uma visão geral conceitual da federação de identidade de cargas de trabalho, consulte Federação de Identidade de cargas de trabalho no Kubernetes habilitado pelo Azure Arc (versão prévia).

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 exige a versão 1.4.23 ou posterior da CLI do Azure. Se você está usando o Azure Cloud Shell, a última versão já está instalada.

Exportar variáveis de ambiente

Para ajudar a simplificar as etapas de configuração das 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 próprios valores:

$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 assinatura 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ê é solicitado a especificar um local. Essa é a localização na qual os metadados do grupo de recursos são armazenados e na qual os recursos são executados no Azure, caso você não especifique outra região durante a criação de recursos.

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

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

O exemplo de saída 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 do AKS Arc com a identidade de workload habilitada

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

• $customlocation_ID: o ID do Azure Resource Manager do local personalizado. O local personalizado é configurado durante a implantação do cluster local do Azure. O administrador de infraestrutura deve fornecer a ID do Gerenciador de Recursos do local personalizado. Você também pode obter o ID do Resource Manager usando $customlocation_ID = $(az customlocation show --name "<your-custom-___location-name>" --resource-group $resource_group_name --query "id" -o tsv), se o administrador da infraestrutura fornecer um nome de local personalizado e um nome de grupo de recursos.
• $logicnet_Id: o ID do Azure Resource Manager da rede lógica Local do Azure criado seguindo essas etapas. Seu administrador de infraestrutura deve lhe fornecer o ID do Resource Manager da rede lógica. Você também pode obter o ID do Resource Manager 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 da infraestrutura fornecer um nome de rede lógica e um nome de grupo de recursos.

Execute o comando az aksarc create com o parâmetro --enable-oidc-issuer --enable-workload-identity. Forneça seu entra-admin-group-object-ids e verifique se você é membro do grupo de administradores 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 será concluído e retornará informações no formato JSON sobre o cluster.

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

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 de seu cluster Kubernetes.

Salve o URL do emissor do OIDC em uma variável de ambiente

Depois que o cluster AKS for criado com êxito, você poderá obter o URL do emissor do 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: crie uma conta de serviço do Kubernetes e vincule-a à 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

Nesta etapa, você cria uma conta de serviço do Kubernetes e a anota com a ID do cliente da identidade gerenciada que você criou na etapa anterior.

Use a conexão de cluster para acessar seu cluster a partir de um dispositivo cliente. Para obter mais informações, consulte Acessar seu cluster de um dispositivo cliente:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

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

$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: crie 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 federadas no Microsoft Entra, consulte Visão geral das credenciais de identidade federadas 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

Etapa 4: Implantar o aplicativo

Quando você implanta seus pods de aplicativos, 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 às propriedades metadata\namespace e spec\serviceAccountName. Especifique 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 - 

Exemplo: conceder permissões para acessar o Azure Key Vault

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 do RBAC (controle de acesso baseado em função) do Azure para conceder ao pod acesso ao cofre de chaves. Para obter mais informações sobre o modelo de permissão rbac do Azure para o Azure Key Vault, consulte Conceder permissão a aplicativos para acessar um cofre de chaves do Azure usando o RBAC do Azure.

1. Crie um cofre de chaves com proteção contra limpeza e autorização RBAC habilitada. Você também poderá usar um cofre de chaves existente se ele estiver configurado para a proteção contra limpeza e a autorização do 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)
   

2. Atribua a função RBAC Responsável pelos segredos do Key Vault 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.

   $CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   
   az role assignment create --assignee-object-id $CALLER_OBJECT_ID --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
   

3. Crie um segredo no cofre de chaves:

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

4. Atribua a função usuário de segredos do Key Vault à identidade gerenciada atribuída pelo usuário que você criou anteriormente. Esta etapa fornece a permissão de identidade gerenciada para ler segredos do cofre de chaves:

   $IDENTITY_PRINCIPAL_ID=$(az identity show --name "$USER_ASSIGNED_IDENTITY_NAME" --resource-group "$resource_group_name" --query principalId --output tsv)
   
   az role assignment create --assignee-object-id $IDENTITY_PRINCIPAL_ID --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
   

5. Crie uma variável de ambiente para a URL do cofre de chaves:

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

6. Implante um pod que faça referência à conta de serviço e à 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 -
   

Excluir o cluster do AKS Arc

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

az aksarc delete -n $aks_cluster_name -g $resource_group_name

Próximas etapas

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

Você também pode ajudar a proteger seu cluster de outras maneiras seguindo as diretrizes no livro de segurança do AKS habilitado pelo Azure Arc.