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

As cargas de trabalho implementadas num cluster AKS requerem credenciais de aplicação Microsoft Entra ou identidades geridas para aceder a recursos protegidos Microsoft Entra, como Azure Key Vault e Microsoft Graph. O ID de carga de trabalho Microsoft Entra integra-se com as capacidades nativas do Kubernetes para federar com fornecedores externos de identidade, permitindo-lhe atribuir identidades de carga de trabalho às suas cargas para autenticar e aceder a outros serviços e recursos.

O ID de carga de trabalho Microsoft Entra utiliza a Projeção de Volume do Token da Conta de Serviço para permitir que os pods usem uma identidade Kubernetes. É emitido um token Kubernetes e a federação OpenID Connect (OIDC) permite que aplicações Kubernetes acedam aos recursos Azure de forma segura com o Microsoft Entra ID, com base em contas de serviço anotadas.

Pode usar o ID de Carga de Trabalho do Microsoft Entra com as bibliotecas cliente Azure Identity ou a coleção Biblioteca de Autenticação da Microsoft (MSAL), juntamente com o registo de aplicações, para autenticar e aceder de forma fluida aos recursos cloud do Azure.

Pré-requisitos

Clusters automáticos AKS

Nos clusters automáticos no AKS, a identidade de carga de trabalho e o emissor OIDC do cluster estão pré-configurados como parte das predefinições de segurança do cluster. Não é necessária qualquer configuração ao nível do cluster antes de usar a identidade da carga de trabalho nos seus pods. Prossiga diretamente para configurar a sua aplicação.

Clusters AKS Standard

• O AKS suporta o ID de carga de trabalho Microsoft Entra na versão 1.22 e superior.
• A versão 2.47.0 ou posterior da CLI do Azure. 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 CLI do Azure (Instalar o CLI do Azure).
• Tens de ativar a identidade da carga de trabalho e o emissor OIDC no teu cluster antes de os teus pods poderem usar a identidade da carga de trabalho. Veja Implementar e configurar identidade de carga de trabalho num cluster AKS.

Limitações

• Você pode ter um máximo de 20 credenciais de identidade federada por identidade gerenciada.
• Demora alguns segundos até que a credencial de identidade federada se propague após ser inicialmente adicionada.
• O add-on de nós virtuais , baseado no projeto open source Virtual Kubelet, não é suportado.
• A criação de credenciais de identidade federada não é suportada em identidades geridas atribuídas pelo utilizador nestas regiões.

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 WorkloadIdentityCredential.
• Utilize WorkloadIdentityCredential diretamente.

Ao solicitar tokens com WorkloadIdentityCredential, especifique os âmbitos no formato <resource>/.default do Microsoft Entra ID v2, como https://management.azure.com/.default. Um URI de recurso bruto, como https://management.azure.com/, pode falhar porque a identidade da carga de trabalho utiliza o endpoint do token Microsoft Entra v2 em vez do fluxo IMDS resource usado pela identidade gerida. Para mais informações sobre como funcionam os telescopios no endpoint do token v2, veja Obter um token.

A tabela seguinte fornece a versão mínima do pacote exigida para a biblioteca cliente de cada ecossistema de linguagem:

Exemplos de código de biblioteca cliente Azure Identity

Os exemplos de código seguintes utilizam o DefaultAzureCredential. Este tipo de credencial utiliza as variáveis de ambiente injetadas pelo webhook que muta a identidade da carga de trabalho para autenticar com o Azure Key Vault. Para ver amostras usando uma das outras abordagens, consulte as bibliotecas de cliente do ecossistema específico.

Substitua <key-vault-url> e <secret-name> pelos valores apropriados para o seu Key Vault e Secret.

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

string keyVaultUrl = Environment.GetEnvironmentVariable("<key-vault-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("<key-vault-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("<key-vault-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("<key-vault-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["<key-vault-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('<key-vault-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 clientes são a versão mínima exigida:

Como funciona

Neste modelo de segurança, o cluster AKS atua como o emissor do token. O Microsoft Entra ID usa o OIDC 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. A sua carga de trabalho pode trocar um token de conta de serviço projetado para o seu volume por um token Microsoft Entra usando a biblioteca cliente Azure Identity ou o MSAL.

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

O diagrama seguinte resume a sequência de autenticação usando OIDC:

Rotação automática do certificado de Webhook

Semelhante a outros complementos de webhook, a operação de rotação automática do certificado de cluster roda o certificado de identidade da carga de trabalho do webhook.

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

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

• Um-para-um, onde uma conta de serviço faz referência a um objeto Microsoft Entra.
• Muitos-para-um, onde múltiplas contas de serviço referenciam o mesmo objeto Microsoft Entra.
• Um-para-muitos, onde uma conta de serviço faz referência a múltiplos objetos Microsoft Entra ao alterar a anotação do ID do cliente. Para obter mais informações, consulte Como federar várias identidades com uma conta de serviço do Kubernetes.

Se você usou a identidade gerenciada pelo 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 principal do Kubernetes, em vez de uma CRD (Definição de Recursos Personalizados). As secções seguintes descrevem uma lista de etiquetas e anotações disponíveis que pode usar para configurar o comportamento ao trocar o token da conta de serviço por um token de acesso Microsoft Entra.

Anotações de conta de serviço

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

Etiquetas de pod

Anotações do pod

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

Utilizar associações de identidade e federação direta na mesma carga de trabalho

As ligações de identidade são uma funcionalidade de pré-visualização que estende a identidade da carga de trabalho para suportar ambientes AKS em grande escala. Em vez de criar uma credencial de identidade federada (FIC) para cada cluster, as ligações de identidade permitem que múltiplos clusters partilhem uma única identidade gerida atribuída pelo utilizador através de um único FIC. Quando ativado, o AKS encaminha os pedidos de tokens dos pods através de um webhook de proxy de associação de identidade que gere a troca de tokens em nome da carga de trabalho.

Um token de conta de serviço projetado tem um único público. Quando as ligações de identidade estão ativadas, o webhook de ligação de identidade define o token predefinido referenciado por AZURE_FEDERATED_TOKEN_FILE para o público api://AKSIdentityBinding, utilizado pelo proxy de ligação de identidade.

A federação direta do ID de carga de trabalho Microsoft Entra (sem associações de identidade) requer um token com o destinatário api://AzureADTokenExchange. A reutilização do ficheiro do token de associação de identidade para federação direta falha com AADSTS700212, porque o público da credencial de identidade federada não corresponde ao público do token.

Para usar associações de identidade para uma identidade gerida e federação direta para outra na mesma carga de trabalho, crie um segundo token de conta de serviço com o público api://AzureADTokenExchange e aponte o código de federação direta para esse ficheiro:

apiVersion: v1
kind: Pod
metadata:
  name: workload-with-ib-and-direct-fic
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: workload-sa
  containers:
  - name: app
    image: <image>
    volumeMounts:
    - name: direct-fic-token
      mountPath: /var/run/secrets/direct-fic
      readOnly: true
    env:
    - name: DIRECT_FIC_TOKEN_FILE
      value: /var/run/secrets/direct-fic/token
  volumes:
  - name: direct-fic-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          audience: api://AzureADTokenExchange
          expirationSeconds: 3600

Utilize AZURE_FEDERATED_TOKEN_FILE para o fluxo de associação de identidade e o ficheiro de token personalizado, como DIRECT_FIC_TOKEN_FILE, para o fluxo direto de credenciais de identidade federada.

Migrar para o ID de Workload do Microsoft Entra

Pode configurar clusters que já executam uma identidade gerida por pods para usar o ID de carga de trabalho do Microsoft Entra de duas maneiras:

• Usa a mesma configuração que implementaste para identidade gerida por pod. Você pode anotar a conta de serviço dentro do namespace com a identidade para habilitar o ID de carga de trabalho do Microsoft Entra e injetar as anotações nos pods.
• Reescreva a sua aplicação para usar a versão mais recente da biblioteca cliente Azure Identity.

Para ajudar a simplificar e facilitar o processo de migração, desenvolvemos um sidecar de migração que converte as transações do Serviço de Metadados de Instância (IMDS) que a sua aplicação faz para OIDC. O sidecar de migração não pretende ser uma solução a longo prazo, mas sim uma forma de começar a funcionar rapidamente no ID de carga de trabalho Microsoft Entra. A execução do sidecar de migração na sua aplicação proxifica as transações IMDS da aplicação 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 seguinte resume as nossas recomendações de migração ou implementação para o seu cluster AKS:

Conteúdo relacionado

• Para saber como configurar o seu pod para autenticação usando uma identidade de carga de trabalho como opção de migração, consulte Modernizar autenticação de aplicações com ID de Carga de Trabalho Microsoft Entra.
• Consulte Implementar e configurar um cluster do AKS com Microsoft Entra ID de Carga de Trabalho, que ajuda a implementar um cluster e configurar uma aplicação de exemplo para usar uma identidade de carga de trabalho.
• Para saber mais sobre as definições de segurança pré-configuradas do AKS Automatic, incluindo a identidade da carga de trabalho, consulte O que é o Azure Kubernetes Service Automatic?