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

As cargas de trabalho implantadas em um cluster do 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, permitindo que você atribua identidades de carga de trabalho às suas cargas de trabalho para autenticar e acessar outros serviços e recursos.

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

Você pode usar a ID de Carga de Trabalho do Microsoft Entra com as bibliotecas de cliente da Identidade do Azure ou a coleção Biblioteca de Autenticação da Microsoft (MSAL), juntamente com o registro de aplicativos, para autenticar e acessar de forma integrada os recursos de nuvem do Azure.

Pré-requisitos

Clusters automáticos AKS

Em clusters do AKS Automático, a identidade de carga de trabalho e o emissor do cluster OIDC são pré-configurados como parte dos padrões de segurança do cluster. Nenhuma configuração em nível de cluster é necessária antes de usar a identidade de carga de trabalho nos seus pods. Continue diretamente para configurar seu aplicativo.

Clusters padrão do AKS

• 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.
• Você deve habilitar a identidade de carga de trabalho e o emissor OIDC no seu cluster antes que seus pods possam usar a identidade de carga de trabalho. Consulte Implantar e configurar a identidade da carga de trabalho em um cluster do AKS.

Limitações

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

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.

Ao solicitar tokens com WorkloadIdentityCredential, informe os escopos usando o formato v2 do Microsoft Entra ID <resource>/.default, como https://management.azure.com/.default. Uma URI bruta de recurso, como https://management.azure.com/, pode falhar porque a identidade da carga de trabalho usa o ponto de extremidade de token v2 do Microsoft Entra em vez do fluxo IMDS resource usado pela identidade gerenciada. Para obter mais informações sobre como os escopos funcionam no ponto de extremidade de token v2, consulte Obter um token.

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

Exemplos de código da biblioteca de clientes do Azure Identity

Os exemplos de código a seguir usam o DefaultAzureCredential. Este tipo de credencial usa as variáveis de ambiente injetadas pelo webhook de mutação da identidade da carga de trabalho para autenticar com o Azure Key Vault. Para ver exemplos usando uma das outras abordagens, consulte as bibliotecas de cliente específicas do ecossistema.

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

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

MSAL (Biblioteca de Autenticação da Microsoft)

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

Como ele funciona

Nesse modelo de segurança, o cluster do AKS atua como o emissor do token. O Microsoft Entra ID usa o OIDC para descobrir as 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 para seu volume por um token Microsoft Entra usando a biblioteca de cliente do Azure Identity ou o MSAL.

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

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

Rotação automática de certificado webhook

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

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 a um, onde uma conta de serviço referencia 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.

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 você pode usar 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.

Rótulos do pod

Anotações de pod

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

Usar vinculações de identidade e federação direta na mesma carga de trabalho

As associações de identidade são um recurso em versão prévia que estende a identidade da carga de trabalho para oferecer suporte a ambientes do AKS em larga escala. Em vez de criar uma FIC (credencial de identidade federada) para cada cluster, as associações de identidade permitem que vários clusters compartilhem uma única identidade gerenciada atribuída pelo usuário por meio de um FIC. Quando habilitado, o AKS direciona as solicitações de token do pod por meio de um webhook de proxy para associação de identidade que gerencia a troca de tokens em nome da carga de trabalho.

Um token de conta de serviço projetado tem um único público-alvo. Quando as associações de identidade são habilitadas, o webhook de associação de identidade define o token padrão referenciado pelo AZURE_FEDERATED_TOKEN_FILE público-alvo api://AKSIdentityBinding, que o proxy de associação de identidade usa.

A federação de ID de carga de trabalho do Microsoft Entra direta (sem associações de identidade) requer um token com o público-alvoapi://AzureADTokenExchange. Reutilizar o arquivo de token de vinculaçã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 vinculações de identidade para uma identidade gerenciada e federação direta para outra na mesma carga de trabalho, projete um segundo token de conta de serviço com a audiência api://AzureADTokenExchange e aponte o código de federação direta para esse arquivo:

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

Use AZURE_FEDERATED_TOKEN_FILE para o fluxo de vinculação de identidade e o arquivo de token personalizado, como DIRECT_FIC_TOKEN_FILE, para o fluxo direto de credencial de identidade federada.

Migrar para Identidade de Carga de Trabalho do Microsoft Entra

Você pode configurar clusters que já executam uma identidade gerenciada por pod para usar o ID de carga de trabalho do Microsoft Entra de duas maneiras:

• 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.
• Reescreva seu aplicativo para usar a versão mais recente da biblioteca de clientes da Identidade do Azure.

Para ajudar a simplificar e facilitar o processo de migração, desenvolvemos um sidecar de migração que converte as transações do IMDS (Serviço de Metadados de Instância) que seu aplicativo faz em OIDC. O sidecar de migração não se destina a ser uma solução a longo prazo, mas sim uma forma de começar a usar rapidamente a ID de Carga de Trabalho do Microsoft Entra. 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 implantação para o cluster do AKS:

Conteúdo relacionado

• 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 a ID de Carga de Trabalho do Microsoft Entra.
• Consulte Implantar e configurar um cluster do AKS com a ID de Carga de Trabalho do Microsoft Entra, que ajuda você a implantar um cluster e configurar um aplicativo de exemplo para usar uma identidade de carga de trabalho.
• Para saber mais sobre as configurações de segurança padrão predefinidas do AKS Automatic, incluindo a identidade de carga de trabalho, consulte O que é o Serviço de Kubernetes do Azure Automatic?