Usare ID dei carichi di lavoro di Microsoft Entra con il servizio Azure Kubernetes

I carichi di lavoro distribuiti in un cluster del servizio Azure Kubernetes richiedono le credenziali dell'applicazione Microsoft Entra o le identità gestite per accedere alle risorse protette di Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. L'ID del carico di lavoro Di Microsoft Entra si integra con le funzionalità native di Kubernetes per la federazione con provider di identità esterne, consentendo di assegnare identità del carico di lavoro ai carichi di lavoro per autenticare e accedere ad altri servizi e risorse.

Il ID dei carichi di lavoro di Microsoft Entra usa la proiezione del volume dei token degli account di servizio (o un account di servizio) per consentire ai pod di usare un'identità Kubernetes. Viene emesso un token Kubernetes e la federazione OIDC (OpenID Connect) consente alle applicazioni Kubernetes di accedere in modo sicuro alle risorse di Azure utilizzando l'ID Microsoft Entra, basandosi su account di servizio annotati.

È possibile usare ID dei carichi di lavoro di Microsoft Entra con le librerie client di Identità di Azure o la raccolta Libreria di Autenticazione Microsoft (MSAL), insieme alla registrazione dell'applicazione, per autenticare e accedere facilmente alle risorse cloud di Azure.

Prerequisiti

• Il servizio Azure Kubernetes supporta il ID dei carichi di lavoro di Microsoft Entra nella versione 1.22 e successiva.
• Interfaccia della riga di comando di Azure versione 2.47.0 o successiva. Eseguire az --version per trovare la versione ed eseguire az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Limitazioni

• È possibile disporre di un massimo di 20 credenziali di identità federate per ogni identità gestita.
• La propagazione delle credenziali dell'identità federata dopo l'aggiunta iniziale richiede alcuni secondi.
• Il componente aggiuntivo nodi virtuali , basato sul progetto open source Virtual Kubelet, non è supportato.
• La creazione di credenziali di identità federate non è supportata nelle identità gestite assegnate dall'utente in queste aree.

Librerie client di Identità di Azure

Nelle librerie client di Identità di Azure scegliere uno degli approcci seguenti:

• Usare DefaultAzureCredential, che tenta di usare WorkloadIdentityCredential.
• Creare un'istanza ChainedTokenCredential che include WorkloadIdentityCredential.
• Usare WorkloadIdentityCredential direttamente.

Quando si richiedono token con WorkloadIdentityCredential, passare gli scope usando il formato <resource>/.default di Microsoft Entra ID v2, ad esempio https://management.azure.com/.default. Un URI di risorsa non elaborato, ad esempio https://management.azure.com/, può avere esito negativo perché l'identità del carico di lavoro usa l'endpoint del token Microsoft Entra v2 anziché il flusso IMDS resource usato dall'identità gestita. Per altre informazioni sul funzionamento degli ambiti nell'endpoint del token v2, vedere Ottenere un token.

La tabella seguente fornisce la versione minima del pacchetto necessaria per ogni libreria client dell'ecosistema linguistico:

Esempi di codice della libreria client di Identità di Azure

Gli esempi di codice seguenti usano .DefaultAzureCredential Questo tipo di credenziale utilizza le variabili d'ambiente iniettate dal webhook di mutazione dell'identità del carico di lavoro per autenticarsi con Azure Key Vault. Per visualizzare gli esempi che usano uno degli altri approcci, vedere le librerie client specifiche dell'ecosistema.

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

Libreria di Autenticazione Microsoft (MSAL)

Le librerie client seguenti sono la versione minima necessaria:

Funzionamento

In questo modello di sicurezza il cluster del servizio Azure Kubernetes funge da emittente del token. Microsoft Entra ID usa OIDC per individuare le chiavi di firma pubbliche e verificare l'autenticità del token dell'account del servizio prima di scambiarlo per un token Microsoft Entra. Il carico di lavoro può scambiare un token dell'account del servizio iniettato nel suo volume per un token Microsoft Entra utilizzando la libreria client di Identità di Azure o MSAL (Microsoft Authentication Library).

La tabella seguente descrive gli endpoint dell'autorità emittente OIDC necessari per il ID dei carichi di lavoro di Microsoft Entra:

Il diagramma seguente riepiloga la sequenza di autenticazione usando OIDC:

Rotazione automatica del certificato di webhook

Analogamente ad altri componenti aggiuntivi webhook, l'operazione di rotazione automatica del certificato del cluster ruota il certificato.

Etichette e annotazioni dell'account del servizio

ID dei carichi di lavoro di Microsoft Entra supporta i mapping seguenti correlati a un account del servizio:

• Uno-a-uno, in cui un account di servizio fa riferimento a un oggetto Microsoft Entra.
• Molti-a-uno, in cui più account di servizio fanno riferimento allo stesso oggetto Microsoft Entra.
• Uno-a-molti, in cui un account di servizio fa riferimento a più oggetti Microsoft Entra modificando l'annotazione dell'ID del client. Per altre informazioni, vedere Come eseguire la federazione di più identità con un account del servizio Kubernetes.

Se è stata usata l’identità gestita da pod di Microsoft Entra, si consideri un account del servizio come un'entità di sicurezza di Azure, a meno che un account del servizio faccia parte dell'API Kubernetes di base, anziché una definizione di risorsa personalizzata (CRD). Le sezioni seguenti descrivono un elenco di etichette e annotazioni disponibili che è possibile usare per configurare il comportamento durante lo scambio del token dell'account del servizio per un token di accesso Microsoft Entra.

Annotazioni dell'account del servizio

Tutte le annotazioni sono facoltative. Se l'annotazione non viene specificata, viene usato il valore predefinito.

Etichette dei pod

Annotazioni dei pod

Tutte le annotazioni sono facoltative. Se l'annotazione non viene specificata, viene usato il valore predefinito.

Usare le associazioni delle identità e la federazione diretta nello stesso carico di lavoro

Un token di account di servizio proiettato ha un solo destinatario. Quando le associazioni di identità sono abilitate, il webhook di associazione di identità imposta il token predefinito a cui AZURE_FEDERATED_TOKEN_FILE fa riferimento il gruppo di destinatari api://AKSIdentityBinding, usato dal proxy di associazione di identità.

La federazione diretta ID dei carichi di lavoro di Microsoft Entra (senza associazioni di identità) richiede un token con il gruppo di destinatari api://AzureADTokenExchange. Il riutilizzo del file del token di associazione di identità per la federazione diretta ha esito negativo perché AADSTS700212 il gruppo di destinatari delle credenziali delle identità federate non corrisponde al gruppo di destinatari del token.

Per usare le associazioni di identità per un'identità gestita e la federazione diretta per un'altra nello stesso carico di lavoro, proiettare un secondo token dell'account del servizio con il api://AzureADTokenExchange gruppo di destinatari e puntare il codice federativo diretto in tale file:

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

Usare AZURE_FEDERATED_TOKEN_FILE per il flusso di associazione di identità e il file di token personalizzato, ad esempio DIRECT_FIC_TOKEN_FILE, per il flusso diretto delle credenziali delle identità federate.

Eseguire la migrazione a ID dei carichi di lavoro di Microsoft Entra

È possibile configurare i cluster che eseguono già un'identità gestita da pod per usare l'ID del carico di lavoro Microsoft Entra usando uno dei due modi seguenti:

• Usare la stessa configurazione implementata per l'identità gestita da pod. È possibile annotare l'account del servizio all'interno dello spazio dei nomi con l'identità per abilitare ID dei carichi di lavoro di Microsoft Entra e inserire le annotazioni nei pod.
• Riscrivere l'applicazione per usare la versione più recente della libreria client di Identità di Azure.

Per facilitare e ottimizzare il processo di migrazione, abbiamo sviluppato uno strumento di supporto che converte le transazioni del servizio di metadati delle istanze (IMDS) effettuate dall'applicazione in OIDC. Il sidecar di migrazione non è progettato per essere una soluzione a lungo termine, ma è un modo per iniziare rapidamente a usare il ID dei carichi di lavoro di Microsoft Entra. L'esecuzione del sidecar di migrazione all'interno del proxy dell'applicazione esegue le transazioni IMDS dell'applicazione in OIDC. L'approccio alternativo consiste nell'eseguire l'aggiornamento a una versione supportata della libreria client di Azure Identity, che supporta l'autenticazione OIDC.

La tabella seguente riepiloga le raccomandazioni relative alla migrazione o alla distribuzione per il cluster del servizio Azure Kubernetes:

Passaggi successivi

• Per informazioni su come configurare il pod per l'autenticazione usando un'identità del carico di lavoro come opzione di migrazione, vedere Modernizzare l'autenticazione dell'applicazione con l'ID del carico di lavoro Microsoft Entra.
• Vedere Distribuire e configurare un cluster AKS con ID dei carichi di lavoro di Microsoft Entra, che consente di distribuire un cluster e configurare un'applicazione di esempio per l'uso di un'identità di carico di lavoro.