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.
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)
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
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 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
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)
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.