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

Articolo
04/14/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 del carico di lavoro Microsoft Entra usa proiezione del volume del token dell'account del servizio consentendo ai pod di usare un'identità Kubernetes (ovvero un account del servizio). Viene rilasciato un token Kubernetes e la federazione OIDC consente alle applicazioni Kubernetes di accedere in modo sicuro alle risorse di Azure con l'ID Microsoft Entra in base agli account del servizio con annotazioni.

L'ID del carico di lavoro Microsoft Entra funziona particolarmente bene con le librerie client di Identità di Azure e la raccolta di Microsoft Authentication Library (MSAL) se si usa la 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 questa nuova funzionalità di autenticazione ed esamina le opzioni disponibili per pianificare la strategia del progetto e la potenziale migrazione dall'identità gestita dai pod di Microsoft Entra.

Nota

Invece di configurare manualmente tutti i passaggi, è disponibile un'altra implementazione denominata Service Connessione or che consente di configurare automaticamente alcuni passaggi. Vedere anche: Che cos'è service Connessione or?

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 avere solo 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.

Diagramma del modello di sicurezza delle identità del carico di lavoro del servizio Azure Kubernetes.

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.

Diagramma della sequenza di autenticazione OIDC dell'identità del carico di lavoro del servizio Azure Kubernetes.

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'identità di Azure, ad eccezione di un account del servizio fa parte dell'API Kubernetes di base, anziché una definizione di risorsa personalizzata (CRD). Di seguito 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 all'identità del carico di lavoro

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. È sufficiente annotare l'account del servizio all'interno dello spazio dei nomi con l'identità e consente all'identità del carico di lavoro di 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 - Esercitazione: Usare un'identità del carico di lavoro con un'applicazione nel servizio Azure Kubernetes
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 l'esercitazione Usare un'identità del carico di lavoro con un'applicazione nel servizio Azure Kubernetes, 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.

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 all'identità del carico di lavoro

Passaggi successivi

Risorse aggiuntive