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

Artigo
08/02/2024

As cargas de trabalho implantadas em um cluster dos Serviços de 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. A ID de Carga de Trabalho do Microsoft Entra integra-se aos recursos nativos do Kubernetes para federar com provedores de identidade externos.

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

A ID de carga de trabalho do Microsoft Entra funciona especialmente bem com as Bibliotecas de clientes da Identidade do Azureou a coleção da Biblioteca de Autenticação da Microsoft (MSAL) junto com o registro de aplicativo. A carga de trabalho poderá usar qualquer uma dessas bibliotecas para autenticar e acessar facilmente os recursos de nuvem do Azure.

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

Observação

Você pode usar Service Connector para ajudá-lo a configurar algumas etapas automaticamente. Veja também: O que é o conector de serviço?

Dependências

O AKS dá suporte à ID de Carga de Trabalho do Microsoft Entra 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 az upgrade para atualizar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

bibliotecas de clientes do Azure Identity

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

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

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

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/identity	3.2.0
Python	azure-identity	1.13.0

Nos exemplos de código a seguir, DefaultAzureCredential é usado. O tipo de credencial usa as variáveis de ambiente injetadas pelo webhook de mutação da Identidade de Carga de Trabalho do Azure 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()

MSAL (Biblioteca de Autenticação da Microsoft)

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

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

Limitações

Você pode ter no máximo 20 credenciais de identidade federadas por identidade gerenciada.
Leva alguns segundos para que a credencial de identidade federada seja propagada após ser inicialmente adicionada.
Não há suporte para o complemento Nós virtuais, que é baseado no Kubelet Virtual do projeto de software livre.
A criação de credenciais de identidade federada não tem suporte em identidades gerenciadas atribuídas pelo usuário nessas regiões.

Como ele funciona

Nesse modelo de segurança, o cluster do AKS atua como o emissor do token. O Microsoft Entra ID usa o OpenID Connect para descobrir as chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de alterná-lo por um token do Microsoft Entra. Sua carga de trabalho pode trocar um token de conta de serviço projetado para seu volume para um token do Microsoft Entra usando a biblioteca de clientes da Identidade do Azure ou a MSAL (Biblioteca de Autenticação da Microsoft).

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

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

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

Rotação automática de certificado webhook

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

Rótulos e anotações da conta de serviço

A ID de carga de trabalho do Microsoft Entra dá suporte aos 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 do 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 da ID do cliente. Para obter mais informações, confira Como federar várias identidades com uma conta de serviço do Kubernetes.

Observação

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

Se você tiver usado identidade gerenciada por pod do Microsoft Entra, pense em uma conta de serviço como uma entidade de segurança do Azure, exceto que uma conta de serviço faz parte da API central do Kubernetes, em vez de uma CRD (Custom Resource Definition ). As seções a seguir descrevem 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á utilizado.

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

Rótulos do pod

Observação

Para aplicativos que usam a identidade da carga de trabalho, é necessário adicionar o rótulo azure.workload.identity/use: "true" à especificação do pod para que 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 falharão após a reinicialização.

Rótulo	Descrição	Valor recomendado	Obrigatório
`azure.workload.identity/use`	Esse rótulo é necessário na especificação do modelo de pod. Somente os pods com esse rótulo são modificados pelo webhook de admissão de modificação azure-workload-identity para injetar as variáveis de ambiente específicas do Azure e o volume de token de conta de serviço projetado.	true	Sim

Anotações de pod

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

Anotação	Descrição	Padrão
`azure.workload.identity/service-account-token-expiration`	Representa o campo `expirationSeconds` para o token de conta de serviço projetada. É um campo opcional que você configura para evitar tempos de inatividade causados por erros durante a atualização do token de conta de serviço. A expiração do token de conta de serviço do Kubernetes não está correlacionada com tokens do Microsoft Entra. Os tokens do Microsoft Entra expiram em 24 horas após serem emitidos. ¹	3600 O intervalo com suporte é de 3600 a 86400.
`azure.workload.identity/skip-containers`	Representa uma lista de contêineres separados por ponto e vírgula para ignorar a adição do volume de token de conta de serviço projetado. Por exemplo, `container1;container2`.	Por padrão, o volume projetado do token de conta de serviço será 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 de proxy é usado para interceptar solicitações de token para IMDS e adquirir um token do Microsoft Entra em nome do usuário com credencial de identidade federada.	true
`azure.workload.identity/proxy-sidecar-port`	Representa a porta do sidecar de proxy.	8000

¹ Terá precedência se a conta de serviço também for anotada.

Como migrar para a ID de Carga de Trabalho do Microsoft Entra

Em um cluster que já executa uma identidade gerenciada por pod, é possível 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 você implementou para a identidade gerenciada por pod. Você pode anotar a conta de serviço no namespace com a identidade para habilitar a ID de Carga de Trabalho do Microsoft Entra e injetar as anotações nos pods.

A segunda opção é regravar o aplicativo para usar a versão mais recente da biblioteca de clientes 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 de IMDS que o aplicativo faz para OIDC (OpenID Connect). O sidecar de migração não é para ser usado como uma solução em longo prazo, mas uma maneira de começar a trabalhar rapidamente na identidade da carga de trabalho. A execução do arquivo secundário de migração no aplicativo faz proxy das transações de IMDS do aplicativo para o OIDC. A abordagem alternativa é atualizar para uma versão com suporte da biblioteca de clientes do Azure Identity, que dá suporte à autenticação de OIDC.

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

Cenário	Descrição
A implantação de cluster nova ou existente executa uma versão com suporte da biblioteca de clientes do Azure Identity	Nenhuma etapa de migração é necessária. Recursos de implantação de exemplo: Implantar e configurar a identidade da carga de trabalho em um novo cluster
A implantação de cluster nova ou existente executa uma versão sem suporte da biblioteca de clientes do Azure Identity	Atualize a imagem de contêiner para usar uma versão do SDK do Azure Identity com suporte ou use o sidecar de migração.

Próximas etapas

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

Compartilhar via

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

Dependências

bibliotecas de clientes do Azure Identity

MSAL (Biblioteca de Autenticação da Microsoft)

Limitações

Como ele funciona

Rotação automática de certificado webhook

Rótulos e anotações da conta de serviço

Anotações de conta de serviço

Rótulos do pod

Anotações de pod

Como migrar para a ID de Carga de Trabalho do Microsoft Entra

Próximas etapas

Recursos adicionais