Compartilhar via


Implantar e configurar a Identidade de Carga de Trabalho em um AKS habilitado pelo cluster do Azure Arc (versão prévia)

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

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

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

  • Crie um cluster do AKS Arc com a identidade de carga de trabalho habilitada (versão prévia).
  • 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.

Importante

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

Observação

Na versão prévia pública, o AKS no Azure Stack HCI dá suporte à habilitação da identidade de carga de trabalho durante a criação do cluster do AKS. No entanto, não há suporte para habilitar a identidade da carga de trabalho após a criação do cluster ou desabilitá-la posteriormente.

Pré-requisitos

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

  • Caso você não tenha uma assinatura do Azure, crie uma conta gratuita do Azure antes de começar.
  • Este artigo requer 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 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 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 sua 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

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 do AKS Arc com a identidade de carga de trabalho habilitada

Para criar um cluster do 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 do Azure Stack HCI. O administrador de infraestrutura deve fornecer a ID do Resource Manager do local personalizado. Você também pode obter a 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 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 de infraestrutura deve fornecer a ID do Resource Manager da rede lógica. Você também pode obter a 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 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 suas ids de objeto de grupo de administrador e verifique se você é membro do grupo de administradores da ID do Microsoft Entra 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 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 do AKS Arc, a habilitação de identidade de carga de trabalho dispara 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, o sinalizador é desabilitado, reduzindo a --service-account-extend-token-expiration validade do token de um ano para um máximo de 24 horas.

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

Depois que o cluster do AKS for criado com êxito, você poderá obter a URL do emissor do OIDC e salvá-la em uma variável de ambiente. Execute o comando a seguir:

$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 associá-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 a 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 do 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 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

Observação

Depois de adicionar uma credencial de identidade federada, ela 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 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 as metadata\namespace propriedades 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 - 

Importante

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

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 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 Oficial de Segredos do RBAC 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.

    az role assignment create --assignee-object-id $MSIPrincipalId --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:

    az role assignment create --assignee-object-id $MSIPrincipalId --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 $aks_cluster_name apply -f -
    

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 da carga de trabalho com a versão mais recente da biblioteca de clientes do Azure Identity.