Usare l'ID del carico di lavoro Microsoft Entra con il servizio Azure Kubernetes

I carichi di lavoro distribuiti in un cluster dei servizi Azure Kubernetes richiedono credenziali dell'applicazione Microsoft Entra o identità gestite per accedere alle risorse protette di Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. Microsoft Entra Workload ID si integra con le funzionalità native di Kubernetes per la federazione con provider di identità esterni.

L'ID dei carichi di lavoro di Microsoft Entra usa proiezione del volume del token dell'account del servizio (ovvero, un account del servizio), per consentire ai pod di usare un'identità Kubernetes. Viene rilasciato un token Kubernetes e la federazione OIDC consente alle applicazioni Kubernetes di accedere in modo sicuro alle risorse di Azure con Microsoft Entra ID in base agli account del servizio con annotazioni.

L'ID dei carichi di lavoro di Microsoft Entra funziona particolarmente bene con le librerie client di Identità di Azure o la raccolta di Microsoft Authentication Library (MSAL), insieme alla registrazione dell'applicazione. Il carico di lavoro può usare una di queste librerie per autenticare e accedere facilmente alle risorse cloud di Azure.

Questo articolo illustra gli ID dei carichi di lavoro di Microsoft Entra ed esamina le opzioni disponibili per pianificare la strategia del progetto e la potenziale migrazione dall'identità gestita dai pod di Microsoft Entra.

Dipendenze

• Il servizio Azure Kubernetes supporta l'ID del carico di lavoro Microsoft Entra nella versione 1.22 e successive.
• 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.

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 direttamente WorkloadIdentityCredential.

La tabella seguente fornisce la versione minima del pacchetto necessaria per la libreria client di ogni ecosistema di lingue.

Negli esempi di codice seguenti viene usato DefaultAzureCredential. Questo tipo di credenziale usa le variabili di ambiente inserite dal webhook di modifica dell'identità del carico di lavoro di Azure per l'autenticazione con 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()

Microsoft Authentication Library (MSAL)

Le librerie client seguenti sono la versione minima richiesta.

Limiti

• È possibile disporre di massimo 20 credenziali di identità federate per ogni identità gestita.
• La propagazione delle credenziali di identità federata dopo l'aggiunta iniziale richiede alcuni secondi.
• I nodi virtuali aggiunti, in base al progetto open source Virtual Kubelet, non sono supportati.
• La creazione di credenziali di identità federate non è supportata nelle identità gestite assegnate dall'utente in queste aree.

Funzionamento

In questo modello di sicurezza il cluster del servizio Azure Kubernetes funge da emittente del token. Microsoft Entra ID usa OpenID Connect 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 proiettato nel volume per un token Microsoft Entra usando la libreria client di Identità di Azure o Microsoft Authentication Library (MSAL).

La tabella seguente descrive gli endpoint dell'autorità emittente OIDC necessari per l'ID del carico di lavoro Microsoft Entra:

Il diagramma seguente riepiloga la sequenza di autenticazione usando OpenID Connect.

Rotazione automatica del certificato webhook

Analogamente ad altri componenti aggiuntivi webhook, il certificato viene ruotato dall'operazione di rotazione automatica del certificato del cluster.

Etichette e annotazioni dell'account del servizio

Microsoft Entra Workload ID 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 del servizio fa riferimento a più oggetti Microsoft Entra modificando l'annotazione ID 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, ad eccezione di un account del servizio fa parte dell'API Kubernetes di base, anziché una definizione di risorsa personalizzata (CRD). Nella seguente sezione viene descritto un elenco di etichette e annotazioni disponibili che possono essere usate 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 è specificata, verrà usato il valore predefinito.

Etichette dei pod

Annotazioni dei pod

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

¹ Ha la precedenza anche se l'account del servizio è annotato.

Come eseguire la migrazione a ID dei carichi di lavoro di Microsoft Entra

In un cluster che esegue già un'identità gestita da pod, è possibile configurarla in modo da usare l'identità del carico di lavoro uno dei due modi. La prima opzione consente di 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.

La seconda opzione consiste nel riscrivere l'applicazione per usare la versione più recente della libreria client di Azure Identity.

Per semplificare e facilitare il processo di migrazione, è stato sviluppato un sidecar di migrazione che converte le transazioni IMDS effettuate dall'applicazione in OpenID Connect (OIDC). Il sidecar della migrazione non è progettato per essere una soluzione a lungo termine, ma un modo per iniziare rapidamente a usare l'identità del carico di lavoro. 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 sulla migrazione o sulla distribuzione per l'identità del carico di lavoro.

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'identità del carico di lavoro.
• Vedere Distribuire e configurare un cluster del servizio Azure Kubernetes con identità del carico di lavoro, che consente di distribuire un cluster del servizio Azure Kubernetes e configurare un'applicazione di esempio per l'uso di un'identità del carico di lavoro.