Uso del id. de carga de trabajo de Microsoft Entra con Azure Kubernetes Service (AKS)

Las cargas de trabajo implementadas en un clúster de Azure Kubernetes Services (AKS) requieren credenciales de aplicación de Microsoft Entra o identidades administradas para acceder a los recursos protegidos de Microsoft Entra, como Azure Key Vault y Microsoft Graph. El id. de carga de trabajo de Microsoft Entra se integra con las funcionalidades nativas de Kubernetes para federarse con proveedores de identidades externos.

Microsoft Entra Workload ID utiliza Service Account Token Volume Projection (es decir, una cuenta de servicio), para permitir que los pods utilicen una identidad Kubernetes. Se emite un token Kubernetes y la Federación OIDC permite a las aplicaciones Kubernetes acceder a los recursos Azure de forma segura con Microsoft Entra ID, basándose en cuentas de servicio anotadas.

El identificador de carga de trabajo de Microsoft Entra funciona especialmente bien con las Bibliotecas cliente de identidad de Azure o la colección deBiblioteca de autenticación de Microsoft (MSAL), junto con registro de aplicaciones. Una carga de trabajo puede usar cualquiera de estas bibliotecas para autenticar los recursos en la nube de Azure y acceder a ellos sin problemas.

Este artículo le ayuda a comprender el identificador de carga de trabajo de Microsoft Entra y revise las opciones disponibles para planear la estrategia del proyecto y la posible migración de la identidad administrada por pods de Microsoft Entra.

Nota:

Puede usar Service Connector para ayudarle a configurar algunos pasos automáticamente. Consulte también: ¿Qué es el conector de servicio?

Dependencias

• AKS admite el id. de carga de trabajo de Microsoft Entra en la versión 1.22 y posteriores.
• La versión 2.47.0 de la CLI de Azure, o cualquier versión posterior. Ejecute az --version para buscar la versión y ejecute az upgrade para actualizar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Bibliotecas cliente de Azure Identity

En las bibliotecas cliente de Azure Identity, elija uno de los métodos siguientes:

• Utilice DefaultAzureCredential, que intenta usar WorkloadIdentityCredential.
• Cree una instancia de ChainedTokenCredential que incluya WorkloadIdentityCredential.
• Use WorkloadIdentityCredential directamente.

En la tabla siguiente se proporciona la versión mínima del paquete necesaria para la biblioteca cliente de cada ecosistema de lenguaje.

Ecosistema	Biblioteca	Versión mínima
.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

En los ejemplos de código siguientes, se usa DefaultAzureCredential. Este tipo de credencial usa las variables de entorno insertadas por el webhook de mutación de Azure Workload Identity para autenticarse con Azure Key Vault.

.NET

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

C++

#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;
}

Go

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

Java

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);
    }
}

Node.js

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);
});

Python

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

Biblioteca de autenticación de Microsoft (MSAL)

Las siguientes bibliotecas cliente son la versión mínima necesaria.

Ecosistema	Biblioteca	Imagen	Ejemplo	Tiene Windows
.NET	microsoft-authentication-library-for-dotnet	ghcr.io/azure/azure-workload-identity/msal-net:latest	Vínculo	Yes
Go	microsoft-authentication-library-for-go	ghcr.io/azure/azure-workload-identity/msal-go:latest	Vínculo	Yes
Java	microsoft-authentication-library-for-java	ghcr.io/azure/azure-workload-identity/msal-java:latest	Vínculo	No
JavaScript	microsoft-authentication-library-for-js	ghcr.io/azure/azure-workload-identity/msal-node:latest	Vínculo	No
Python	microsoft-authentication-library-for-python	ghcr.io/azure/azure-workload-identity/msal-python:latest	Vínculo	No

Limitaciones

• Puede tener un máximo de 20 credenciales de identidad federada por identidad administrada.
• La credencial de identidad federada tarda unos segundos en propagarse después de agregarse inicialmente.
• El complemento de nodos virtuales, basado en el proyecto de código abierto Virtual Kubelet, no es compatible.
• La creación de credenciales de identidad federada no está admitida en identidades administradas asignadas por el usuario en estas regiones.

Funcionamiento

En este modelo de seguridad, el clúster de AKS actúa como emisor de tokens. Microsoft Entra ID usa OpenID Connect para detectar claves de firma pública y comprobar la autenticidad del token de cuenta de servicio antes de intercambiarlo por un token de Microsoft Entra. La carga de trabajo puede intercambiar un token de cuenta de servicio proyectado en su volumen para un token de Microsoft Entra mediante la biblioteca cliente de Identidad de Azure o la Biblioteca de autenticación de Microsoft (MSAL).

En la tabla siguiente se describen los puntos de conexión de emisor de OIDC necesarios para el id. de carga de trabajo de Microsoft Entra:

Punto de conexión	Descripción
{IssuerURL}/.well-known/openid-configuration	También conocido como el documento de detección de OIDC, que contiene los metadatos sobre las configuraciones del emisor.
{IssuerURL}/openid/v1/jwks	Contiene las claves de firma públicas que utiliza Microsoft Entra ID para comprobar la autenticidad del token de la cuenta de servicio.

En el diagrama siguiente, se resume la secuencia de autenticación mediante OpenID Connect.

Rotación automática de certificados webhook

Al igual que con otros complementos de webhook, el certificado se rota mediante la operación de rotación automática del certificado del clúster.

Anotaciones y etiquetas de la cuenta de servicio

El id. de carga de trabajo de Microsoft Entra admite las siguientes asignaciones relacionadas con una cuenta de servicio:

• Uno a uno, donde una cuenta de servicio hace referencia a un objeto Microsoft Entra.
• Muchos a uno, cuando varias cuentas de servicio hacen referencia al mismo objeto de Microsoft Entra.
• Uno a varios, donde una cuenta de servicio hace referencia a varios objetos de Microsoft Entra cambiando la anotación de identificador de cliente. Para más información, consulte Cómo federar varias identidades con una cuenta de servicio de Kubernetes.

Nota:

Si se actualizan las anotaciones de la cuenta de servicio, debe reiniciar el pod para que los cambios surtan efecto.

Si ha usado la Identidad administrada por pods de Microsoft Entra, considere una cuenta de servicio como una entidad de seguridad principal de Azure, con la diferencia de que una cuenta de servicio forma parte de la API central de Kubernetes, en lugar de una Definición personalizada de recursos (CRD). En las secciones siguientes se describe una lista de etiquetas y anotaciones disponibles que se pueden usar para configurar el comportamiento al intercambiar el token de cuenta de servicio para un token de acceso de Microsoft Entra.

Anotaciones de cuenta de servicio

Todas las anotaciones son opcionales. Si no se especifica la anotación, se usará el valor predeterminado.

Annotation	Descripción	Valor predeterminado
azure.workload.identity/client-id	Representa la aplicación Microsoft Entra de Azure AD que se va a usar con el pod.
azure.workload.identity/tenant-id	Representa el id. del inquilino de Azure La aplicación Microsoft Entra está registrada.	Variable de entorno AZURE_TENANT_ID extraída de ConfigMap azure-wi-webhook-config.
azure.workload.identity/service-account-token-expiration	Representa el campo expirationSeconds para el token de cuenta de servicio proyectado. Se trata de un campo opcional que se configura para evitar el tiempo de inactividad provocado por errores durante la actualización del token de cuenta de servicio. La expiración del token de la cuenta de servicio de Kubernetes no está correlacionada con los tokens de Microsoft Entra. Los tokens de Microsoft Entra expiran 24 horas después de su emisión.	3600 El intervalo admitido es de 3600 a 86400.

Etiquetas de pod

Nota:

Para las aplicaciones que usan la identidad de la carga de trabajo, es necesario agregar el etiquetado azure.workload.identity/use: "true" a la especificación del pod para que AKS mueva la identidad de la carga de trabajo a un escenario Fail Close (de cierre fallido) para proporcionar un comportamiento coherente y fiable para los pods que necesiten usar la identidad de la carga de trabajo. De lo contrario, se produce un error en los pods después de reiniciarse.

Etiqueta	Descripción	Valor recomendado	Obligatorio
azure.workload.identity/use	Esta etiqueta es necesaria en la especificación de plantilla de pod. Solo los pods con esta etiqueta se mutan mediante el webhook de admisión de mutación de azure-workload-identity para insertar las variables de entorno específicas de Azure y el volumen de tokens de cuenta de servicio proyectado.	true	Sí

Anotaciones de pod

Todas las anotaciones son opcionales. Si no se especifica la anotación, se usará el valor predeterminado.

Annotation	Descripción	Valor predeterminado
azure.workload.identity/service-account-token-expiration	Representa el campo expirationSeconds para el token de cuenta de servicio proyectado. Se trata de un campo opcional que se configurar para evitar cualquier tiempo de espera provocado por errores durante la actualización del token de cuenta de servicio. La expiración del token de la cuenta de servicio de Kubernetes no está correlacionada con los tokens de Microsoft Entra. Los tokens de Microsoft Entra expiran 24 horas después de su emisión. 1	3600 El intervalo admitido es de 3600 a 86400.
azure.workload.identity/skip-containers	Representa una lista separada por punto y coma de contenedores para omitir la adición de un volumen de token de cuenta de servicio proyectado. Por ejemplo, container1;container2.	De manera predeterminada, el volumen de token de cuenta de servicio proyectado se agrega a todos los contenedores si la cuenta de servicio está etiquetada con azure.workload.identity/use: true.
azure.workload.identity/inject-proxy-sidecar	Inserta un contenedor de inicialización de proxy y un sidecar de proxy en el pod. El sidecar de proxy se usa para interceptar las solicitudes de token a IMDS y adquirir un token de Microsoft Entra en nombre del usuario con credenciales de identidad federada.	true
azure.workload.identity/proxy-sidecar-port	Representa el puerto del sidecar de proxy.	8000

¹ Tiene prioridad si la cuenta de servicio también está anotada.

Migración a Entra Workload ID

En un clúster que ya ejecuta una identidad administrada por pods, puede configurarlo para que use la identidad de carga de trabajo de una de dos maneras. La primera opción permite usar la misma configuración que ha implementado para la identidad administrada por pods. Puede anotar la cuenta de servicio dentro del espacio de nombres con la identidad para habilitar entra Workload ID e insertar las anotaciones en los pods.

La segunda opción es reescribir la aplicación para usar la versión más reciente de la biblioteca cliente de Azure Identity.

Para ayudar a optimizar y facilitar el proceso de migración, desarrollamos un sidecar de migración que convierte las transacciones de IMDS que hace la aplicación a OpenID Connect (OIDC). El sidecar de migración no está pensado como una solución a largo plazo, sino como una manera de empezar a trabajar rápidamente con la identidad de carga de trabajo. Ejecutar el sidecar de migración dentro de la aplicación redirige las transacciones de IMDS de la aplicación a OIDC. El enfoque alternativo es actualizar a una versión admitida de la biblioteca cliente de Azure Identity, que admite la autenticación de OIDC.

En la tabla siguiente, se resumen las recomendaciones de migración o implementación para la identidad de carga de trabajo.

Escenario	Descripción
La implementación nueva o existente de un clúster ejecuta una versión compatible de la biblioteca cliente de Azure Identity.	No se requiere ningún paso de migración. Recursos de implementación de ejemplo: Implementación y configuración de la identidad de carga de trabajo en un nuevo clúster
La implementación nueva o existente de un clúster ejecuta una versión no compatible de la biblioteca cliente de Azure Identity.	Actualice la imagen de contenedor para utilizar una versión compatible del SDK de Azure Identity, o bien use el sidecar de migración.

Pasos siguientes

• Para información sobre cómo configurar el pod para la autenticación mediante una identidad de carga de trabajo como opción de migración, consulte Modernización de la autenticación de aplicaciones con identidad de carga de trabajo.
• Consulte Implementación y configuración de un clúster de AKS con identidad de carga de trabajo, que le ayuda a implementar un clúster de Azure Kubernetes Service y a configurar una aplicación de ejemplo para usar una identidad de carga de trabajo.