Usar a ID de Carga de Trabalho do Microsoft Entra com o Serviço Kubernetes do Azure (AKS)

Artigo
11/17/2023

As cargas de trabalho implantadas em um cluster dos Serviços Kubernetes do Azure (AKS) exigem credenciais de aplicativo ou identidades gerenciadas do Microsoft Entra para acessar recursos protegidos do Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. O Microsoft Entra Workload ID integra-se com os recursos nativos do Kubernetes para federar com provedores de identidade externos.

O ID de Carga de Trabalho do Microsoft Entra usa a Projeção de Volume de Token de Conta de Serviço permitindo que os pods usem uma identidade Kubernetes (ou seja, uma conta de serviço). Um token Kubernetes é emitido e a federação OIDC permite que os aplicativos Kubernetes acessem recursos do Azure com segurança com a ID do Microsoft Entra com base em contas de serviço anotadas.

A ID de Carga de Trabalho do Microsoft Entra funciona especialmente bem com as bibliotecas de cliente do Azure Identity e a coleção da Biblioteca de Autenticação da Microsoft (MSAL) se você estiver usando o registro de aplicativo. Sua carga de trabalho pode usar qualquer uma dessas bibliotecas para autenticar e acessar perfeitamente os recursos de nuvem do Azure.

Este artigo ajuda você a entender esse novo recurso de autenticação e analisa as opções disponíveis para planejar sua estratégia de projeto e possível migração da identidade gerenciada por pod do Microsoft Entra.

Nota

Em vez de configurar todas as etapas manualmente, há outra implementação chamada Service Connector que irá ajudá-lo a configurar algumas etapas automaticamente. Consulte também: O que é o Service Connector?

Dependências

O AKS suporta o Microsoft Entra Workload ID na versão 1.22 e superior.
A CLI do Azure 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, veja Install Azure CLI (Instalar o Azure CLI).

Bibliotecas de cliente do Azure Identity

Nas bibliotecas de cliente do Azure Identity, escolha uma das seguintes abordagens:

Use DefaultAzureCredential, que tenta usar o WorkloadIdentityCredential.
Crie uma ChainedTokenCredential instância que inclua WorkloadIdentityCredentialo .
Use WorkloadIdentityCredential diretamente.

A tabela a seguir fornece a versão mínima do pacote necessária para a biblioteca de cliente de cada ecossistema de idiomas.

Ecossistema	Biblioteca	Versão Mínima
.NET	Azure.Identity	1.9.0
C++	azure-identity-cpp	1.6.0
Go	azidentity	1.3.0
Java	azure-identity	1.9.0
Node.js	@azure/identidade	3.2.0
Python	azure-identity	1.13.0

Nos exemplos de código a seguir, DefaultAzureCredential é usado. Esse tipo de credencial usa as variáveis de ambiente injetadas pelo webhook mutante do Azure Workload Identity para autenticar com o Azure Key Vault.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");

var client = new SecretClient(
    new Uri(keyVaultUrl),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync(secretName);

#include <cstdlib>
#include <azure/identity.hpp>
#include <azure/keyvault/secrets/secret_client.hpp>

using namespace Azure::Identity;
using namespace Azure::Security::KeyVault::Secrets;

int main()
{
  const char* keyVaultUrl = std::getenv("KEYVAULT_URL");
  const char* secretName = std::getenv("SECRET_NAME");
  auto credential = std::make_shared<DefaultAzureCredential>();

  SecretClient client(keyVaultUrl, credential);
  Secret secret = client.GetSecret(secretName).Value;

  return 0;
}

package main

import (
	"context"
	"os"

	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets"
    "k8s.io/klog/v2"
)

func main() {
	keyVaultUrl := os.Getenv("KEYVAULT_URL")
	secretName := os.Getenv("SECRET_NAME")

	credential, err := azidentity.NewDefaultAzureCredential(nil)
	if err != nil {
		klog.Fatal(err)
	}

	client, err := azsecrets.NewClient(keyVaultUrl, credential, nil)
	if err != nil {
		klog.Fatal(err)
	}

	secret, err := client.GetSecret(context.Background(), secretName, "", nil)
	if err != nil {
		klog.ErrorS(err, "failed to get secret", "keyvault", keyVaultUrl, "secretName", secretName)
		os.Exit(1)
	}
}

import java.util.Map;

import com.azure.security.keyvault.secrets.SecretClient;
import com.azure.security.keyvault.secrets.SecretClientBuilder;
import com.azure.security.keyvault.secrets.models.KeyVaultSecret;
import com.azure.identity.DefaultAzureCredentialBuilder;
import com.azure.identity.DefaultAzureCredential;

public class App {
    public static void main(String[] args) {
        Map<String, String> env = System.getenv();
        String keyVaultUrl = env.get("KEYVAULT_URL");
        String secretName = env.get("SECRET_NAME");

        SecretClient client = new SecretClientBuilder()
                .vaultUrl(keyVaultUrl)
                .credential(new DefaultAzureCredentialBuilder().build())
                .buildClient();
        KeyVaultSecret secret = client.getSecret(secretName);
    }
}

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";

const main = async () => {
    const keyVaultUrl = process.env["KEYVAULT_URL"];
    const secretName = process.env["SECRET_NAME"];

    const credential = new DefaultAzureCredential();
    const client = new SecretClient(keyVaultUrl, credential);

    const secret = await client.getSecret(secretName);
}

main().catch((error) => {
    console.error("An error occurred:", error);
    process.exit(1);
});

import os

from azure.keyvault.secrets import SecretClient
from azure.identity import DefaultAzureCredential

def main():
    keyvault_url = os.getenv('KEYVAULT_URL', '')
    secret_name = os.getenv('SECRET_NAME', '')

    client = SecretClient(vault_url=keyvault_url, credential=DefaultAzureCredential())
    secret = client.get_secret(secret_name)

if __name__ == '__main__':
    main()

Biblioteca de Autenticação da Microsoft (MSAL)

As seguintes bibliotecas de cliente são a versão mínima necessária.

Ecossistema	Biblioteca	Image	Exemplo	Tem Windows
.NET	Biblioteca de autenticação da Microsoft para dotnet	`ghcr.io/azure/azure-workload-identity/msal-net:latest`	Ligação	Sim
Go	Biblioteca de Autenticação da Microsoft para uso	`ghcr.io/azure/azure-workload-identity/msal-go:latest`	Ligação	Sim
Java	Biblioteca de autenticação da Microsoft para java	`ghcr.io/azure/azure-workload-identity/msal-java:latest`	Ligação	Não
JavaScript	Biblioteca de autenticação da Microsoft para js	`ghcr.io/azure/azure-workload-identity/msal-node:latest`	Ligação	Não
Python	Biblioteca de autenticação da Microsoft para python	`ghcr.io/azure/azure-workload-identity/msal-python:latest`	Ligação	Não

Limitações

Você só pode ter 20 credenciais de identidade federada por identidade gerenciada.
A propagação da credencial de identidade federada demora alguns segundos depois de ter sido inicialmente adicionada.
A adição de nós virtuais, com base no projeto de código aberto Virtual Kubelet, não é suportada.
A criação de credenciais de identidade federada não é suportada em identidades gerenciadas atribuídas pelo usuário nessas regiões.

Como funciona

Neste modelo de segurança, o cluster AKS atua como emissor de token, o Microsoft Entra ID usa o OpenID Connect para descobrir chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de trocá-lo por um token do Microsoft Entra. Sua carga de trabalho pode trocar um token de conta de serviço projetado em seu volume por um token do Microsoft Entra usando a biblioteca de cliente do Azure Identity ou a Biblioteca de Autenticação da Microsoft.

Diagrama do modelo de segurança de identidade da carga de trabalho AKS.

A tabela a seguir descreve os pontos de extremidade do emissor OIDC necessários para o ID de carga de trabalho do Microsoft Entra:

Ponto final	Description
`{IssuerURL}/.well-known/openid-configuration`	Também conhecido como documento de descoberta OIDC. Ele contém os metadados sobre as configurações do emissor.
`{IssuerURL}/openid/v1/jwks`	Isso contém a(s) chave(s) de assinatura pública que o Microsoft Entra ID usa para verificar a autenticidade do token de conta de serviço.

O diagrama a seguir resume a sequência de autenticação usando o OpenID Connect.

Diagrama da sequência de autenticação OIDC da identidade da carga de trabalho AKS.

Rotação automática do certificado Webhook

Semelhante a outros addons webhook, o certificado é girado pela operação de rotação automática do certificado de cluster.

Etiquetas e anotações da conta de serviço

O Microsoft Entra Workload ID suporta os seguintes mapeamentos relacionados a uma conta de serviço:

Um para um em que uma conta de serviço faz referência a um objeto do Microsoft Entra.
Muitos-para-um em que várias contas de serviço fazem referência ao mesmo objeto Microsoft Entra.
Um para muitos em que uma conta de serviço faz referência a vários objetos do Microsoft Entra alterando a anotação de ID do cliente. Para obter mais informações, consulte Como federar várias identidades com uma conta de serviço do Kubernetes.

Nota

Se as anotações da conta de serviço forem atualizadas, será necessário reiniciar o pod para que as alterações entrem em vigor.

Se você usou a identidade gerenciada por pod do Microsoft Entra, pense em uma conta de serviço como uma Identidade do Azure, exceto que uma conta de serviço faz parte da API principal do Kubernetes, em vez de uma CRD (Definição de Recursos Personalizados). A seguir descrevemos uma lista de rótulos e anotações disponíveis que podem ser usados para configurar o comportamento ao trocar o token de conta de serviço por um token de acesso do Microsoft Entra.

Anotações de conta de serviço

Todas as anotações são opcionais. Se a anotação não for especificada, o valor padrão será usado.

Anotação	Description	Predefinido
`azure.workload.identity/client-id`	Representa o aplicativo Microsoft Entra ID do cliente a ser usado com o pod.
`azure.workload.identity/tenant-id`	Representa a ID do locatário do Azure onde o O aplicativo Microsoft Entra está registrado.	AZURE_TENANT_ID variável de ambiente extraída do `azure-wi-webhook-config` ConfigMap.
`azure.workload.identity/service-account-token-expiration`	Representa o `expirationSeconds` campo para o token de conta de serviço projetado. É um campo opcional que você configura para evitar tempo de inatividade Causados por erros durante a atualização do token da conta de serviço. A expiração do token da conta de serviço do Kubernetes não está correlacionada com os tokens do Microsoft Entra. Os tokens Microsoft Entra expiram em 24 horas após serem emitidos.	3600 O intervalo suportado é 3600-86400.

Rótulos de pod

Nota

Para aplicativos que usam identidade de carga de trabalho, é necessário adicionar o rótulo azure.workload.identity/use: "true" à especificação do pod para que o AKS mova a identidade da carga de trabalho para um cenário de Fail Close para fornecer um comportamento consistente e confiável para pods que precisam usar a identidade da carga de trabalho. Caso contrário, os pods falham depois de serem reiniciados.

Label	Description	Valor recomendado	Necessário
`azure.workload.identity/use`	Este rótulo é necessário na especificação do modelo pod. Somente pods com esse rótulo são mutados pelo webhook azure-workload-identity mutating admission para injetar as variáveis de ambiente específicas do Azure e o volume de token de conta de serviço projetado.	verdadeiro	Sim

Anotações do pod

Todas as anotações são opcionais. Se a anotação não for especificada, o valor padrão será usado.

Anotação	Description	Predefinido
`azure.workload.identity/service-account-token-expiration`	Representa o `expirationSeconds` campo para o token de conta de serviço projetado. É um campo opcional que você configura para evitar qualquer tempo de inatividade causado por erros durante a atualização do token da conta de serviço. A expiração do token da conta de serviço do Kubernetes não está correlacionada com os tokens do Microsoft Entra. Os tokens Microsoft Entra expiram em 24 horas após serem emitidos. ¹	3600 O intervalo suportado é 3600-86400.
`azure.workload.identity/skip-containers`	Representa uma lista separada por ponto-e-vírgula de contêineres para ignorar a adição do volume de token de conta de serviço projetado. Por exemplo, `container1;container2`.	Por padrão, o volume de token de conta de serviço projetado é adicionado a todos os contêineres se a conta de serviço estiver rotulada com `azure.workload.identity/use: true`.
`azure.workload.identity/inject-proxy-sidecar`	Injeta um contêiner de inicialização de proxy e um sidecar de proxy no pod. O sidecar proxy é usado para intercetar solicitações de token para o IMDS e adquirir um token Microsoft Entra em nome do usuário com credencial de identidade federada.	verdadeiro
`azure.workload.identity/proxy-sidecar-port`	Representa a porta do sidecar proxy.	8000

1 Tem precedência se a conta de serviço também estiver anotada.

Como migrar para a identidade da carga de trabalho

Em um cluster que já esteja executando uma identidade gerenciada por pod, você pode configurá-lo para usar a identidade de carga de trabalho de duas maneiras. A primeira opção permite que você use a mesma configuração que implementou para a identidade gerenciada por pod hoje. Você só precisa anotar a conta de serviço dentro do namespace com a identidade, e isso permite que a identidade da carga de trabalho injete as anotações nos pods.

A segunda opção é reescrever seu aplicativo para usar a versão mais recente da biblioteca de cliente do Azure Identity.

Para ajudar a simplificar e facilitar o processo de migração, desenvolvemos um sidecar de migração que converte as transações IMDS que seu aplicativo faz para o OpenID Connect (OIDC). O sidecar de migração não pretende ser uma solução de longo prazo, mas uma maneira de começar a trabalhar rapidamente na identidade da carga de trabalho. A execução do sidecar de migração em seu aplicativo faz o proxy das transações IMDS do aplicativo para o OIDC. A abordagem alternativa é atualizar para uma versão com suporte da biblioteca de cliente do Azure Identity , que dá suporte à autenticação OIDC.

A tabela a seguir resume nossas recomendações de migração ou implantação para identidade de carga de trabalho.

Cenário	Description
A implantação de cluster nova ou existente executa uma versão com suporte da biblioteca de cliente do Azure Identity	Nenhuma etapa de migração é necessária. Exemplos de recursos de implantação: - Implantar e configurar a identidade da carga de trabalho em um novo cluster - Tutorial: Usar uma identidade de carga de trabalho com um aplicativo no AKS
A implantação de cluster nova ou existente executa uma versão sem suporte da biblioteca de cliente do Azure Identity	Atualize a imagem do contêiner para usar uma versão com suporte do SDK do Azure Identity ou use o sidecar de migração.

Próximos passos

Para saber como configurar seu pod para autenticar usando uma identidade de carga de trabalho como uma opção de migração, consulte Modernizar a autenticação de aplicativos com identidade de carga de trabalho.
Consulte o tutorial Usar uma identidade de carga de trabalho com um aplicativo no Serviço Kubernetes do Azure (AKS), que ajuda você a implantar um cluster do Serviço Kubernetes do Azure e configurar um aplicativo de exemplo para usar uma identidade de carga de trabalho.

Usar a ID de Carga de Trabalho do Microsoft Entra com o Serviço Kubernetes do Azure (AKS)

Dependências

Bibliotecas de cliente do Azure Identity

Biblioteca de Autenticação da Microsoft (MSAL)

Limitações

Como funciona

Rotação automática do certificado Webhook

Etiquetas e anotações da conta de serviço

Anotações de conta de serviço

Rótulos de pod

Anotações do pod

Como migrar para a identidade da carga de trabalho

Próximos passos

Recursos adicionais