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

Articolo
08/06/2024

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.

Nota

È possibile usare Connettore di servizi per configurare automaticamente alcuni passaggi. Vedere anche: Che cos'è Connettore di servizi?

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.

Ecosistema	Libreria	Versione minima
.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

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.

Ecosistema	Libreria	Image	Esempio	Dispone di Windows
.NET	Microsoft Authentication Library-for-dotnet	`ghcr.io/azure/azure-workload-identity/msal-net:latest`	Collegamento	Sì
Go	Microsoft Authentication Library-for-go	`ghcr.io/azure/azure-workload-identity/msal-go:latest`	Collegamento	Sì
Java	Microsoft Authentication Library-for-java	`ghcr.io/azure/azure-workload-identity/msal-java:latest`	Collegamento	No
JavaScript	Microsoft Authentication Library-for-js	`ghcr.io/azure/azure-workload-identity/msal-node:latest`	Collegamento	No
Python	Microsoft Authentication Library-for-python	`ghcr.io/azure/azure-workload-identity/msal-python:latest`	Collegamento	No

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:

Endpoint	Descrizione
`{IssuerURL}/.well-known/openid-configuration`	Noto anche come documento di individuazione OIDC. Contiene i metadati relativi alle configurazioni dell'autorità emittente.
`{IssuerURL}/openid/v1/jwks`	Contiene le chiavi di firma pubbliche usate da Microsoft Entra ID per verificare l'autenticità del token dell'account del servizio.

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.

Nota

Se le annotazioni dell'account del servizio vengono aggiornate, è necessario riavviare il pod per rendere effettive le modifiche.

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.

Annotazione	Descrizione	Default
`azure.workload.identity/client-id`	Rappresenta l'applicazione Microsoft Entra ID client da usare con il pod.
`azure.workload.identity/tenant-id`	Rappresenta l'ID tenant di Azure in cui l'applicazione Microsoft Entra è registrata.	Variabile di ambiente AZURE_TENANT_ID estratta da `azure-wi-webhook-config` ConfigMap.
`azure.workload.identity/service-account-token-expiration`	Rappresenta il campo `expirationSeconds` per l'oggetto token dell'account del servizio proiettato. Si tratta di un campo facoltativo configurato per evitare tempi di inattività causato da errori durante l'aggiornamento del token dell'account del servizio. La scadenza del token dell'account del servizio Kubernetes non è correlata ai token di Microsoft Entra. I token di Microsoft Entra scadono entro 24 ore dall'emissione.	3600 L'intervallo supportato è 3600-86400.

Etichette dei pod

Nota

Per le applicazioni che usano l'identità del carico di lavoro, è necessario aggiungere l'etichetta azure.workload.identity/use: "true" alla specifica del pod per il servizio Azure Kubernetes per spostare l'identità del carico di lavoro in uno scenario di chiusura non riuscita per fornire un comportamento coerente e affidabile per i pod che devono usare l'identità del carico di lavoro. In caso contrario, i pod avranno esito negativo dopo il riavvio.

Etichetta	Descrizione	Valore consigliato	Richiesto
`azure.workload.identity/use`	Questa etichetta è necessaria nella specifica del modello di pod. Solo i pod con questa etichetta vengono modificati dal webhook azure-workload-identity che modifica l'ammissione per inserire le variabili di ambiente specifiche di Azure e il volume del token dell'account del servizio proiettato.	true	Sì

Annotazioni dei pod

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

Annotazione	Descrizione	Default
`azure.workload.identity/service-account-token-expiration`	Rappresenta il campo `expirationSeconds` per il token dell'account del servizio proiettato. Si tratta di un campo facoltativo configurato per evitare tempi di inattività causati da errori durante l'aggiornamento del token dell'account del servizio. La scadenza del token dell'account del servizio Kubernetes non è correlata ai token di Microsoft Entra. I token di Microsoft Entra scadono entro 24 ore dall'emissione. ¹	3600 L'intervallo supportato è 3600-86400.
`azure.workload.identity/skip-containers`	Rappresenta un elenco delimitato da punti e virgola dei contenitori per ignorare l'aggiunta del volume di token dell'account del servizio proiettato. Ad esempio, `container1;container2`.	Per impostazione predefinita, il volume del token dell'account del servizio proiettato viene aggiunto a tutti i contenitori se l'account del servizio è etichettato con `azure.workload.identity/use: true`.
`azure.workload.identity/inject-proxy-sidecar`	Inserisce un contenitore proxy init e un sidecar proxy nel pod. Il sidecar proxy viene usato per intercettare le richieste di token a IMDS e acquisire un token Microsoft Entra per conto dell'utente con credenziali di identità federate.	true
`azure.workload.identity/proxy-sidecar-port`	Rappresenta la porta del sidecar proxy.	8000

¹ 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.

Scenario	Descrizione
La distribuzione di cluster nuova o esistente esegue una versione supportata della libreria client di Identità di Azure	Non sono necessari passaggi di migrazione. Risorse di distribuzione di esempio: distribuire e configurare l'identità del carico di lavoro in un nuovo cluster
La distribuzione di cluster nuovi o esistenti esegue una versione non supportata della libreria client di Identità di Azure	Aggiornare l'immagine del contenitore per usare una versione supportata di Azure Identity SDK o usare il sidecar di migrazione.

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.

Condividi tramite

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

Dipendenze

Librerie client di Identità di Azure

Microsoft Authentication Library (MSAL)

Limiti

Funzionamento

Rotazione automatica del certificato webhook

Etichette e annotazioni dell'account del servizio

Annotazioni dell'account del servizio

Etichette dei pod

Annotazioni dei pod

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

Passaggi successivi

Risorse aggiuntive