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

Artículo
11/17/2023

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.

Id. de carga de trabajo de Microsoft Entra utiliza la proyección de volumen de token de cuenta de servicio lo que permite que los pods utilicen una identidad de Kubernetes (es decir, una cuenta de servicio). Se emite un token de Kubernetes y de federación OIDC permite que las aplicaciones de Kubernetes accedan de forma segura a los recursos de Azure con Microsoft Entra ID basado en cuentas de servicio anotadas.

El id. de carga de trabajo de Microsoft Entra funciona especialmente bien con las bibliotecas cliente de identidad de Azure y la colección de la biblioteca de autenticación de Microsoft (MSAL) si utiliza registro de aplicación. 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 esta nueva característica de autenticación y revisa las opciones disponibles para planear la estrategia del proyecto y la posible migración de la identidad administrada por pods de Microsoft Entra.

Nota:

En lugar de configurar todos los pasos manualmente, hay otra implementación denominada Conector de servicio que le ayudará 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.

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

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

Solo puede tener 20 credenciales de identidad federada por identidad administrada.
La credencial de identidad federada tarda unos segundos en propagarse después de agregarse inicialmente.
No se admite el complemento de nodos virtuales basado en el proyecto de código abierto Virtual Kubelet.
La creación de credenciales de identidad federada no está admitida en identidades administradas asignadas por el usuario en estas regiones.

Cómo funciona

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.

Diagrama del modelo de seguridad de la identidad de carga de trabajo de AKS.

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.

Diagrama de la secuencia de autenticación de OIDC de la identidad de carga de trabajo de AKS.

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 en el que una cuenta de servicio hace referencia a un objeto Microsoft Entra.
Varios a uno en los que 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 id. 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 identidad administrada por pods de Microsoft Entra, piense en una cuenta de servicio como una identidad de Azure, excepto que una cuenta de servicio forma parte de la API principal de Kubernetes, en lugar de una definición de recursos personalizados (CRD). A continuación 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. ¹	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 la identidad de carga de trabajo

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 le permite usar la misma configuración que implementó hoy para la identidad administrada por pods. Solo tiene que anotar la cuenta de servicio dentro del espacio de nombres con la identidad, lo que permite que la identidad de carga de trabajo inserte 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 clúster nuevo - Tutorial: Uso de una identidad de carga de trabajo con una aplicación en AKS
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 el tutorial Uso de una identidad de carga de trabajo con una aplicación en Azure Kubernetes Service (AKS), que le permite implementar un clúster de Azure Kubernetes Service y configurar una aplicación de ejemplo para usar una identidad de carga de trabajo.