Microsoft Entra Workload-ID gebruiken met Azure Kubernetes Service (AKS)

2024-09-24

Voor workloads die zijn geïmplementeerd op een AKS-cluster (Azure Kubernetes Services) zijn microsoft Entra-toepassingsreferenties of beheerde identiteiten vereist voor toegang tot met Microsoft Entra beveiligde resources, zoals Azure Key Vault en Microsoft Graph. Microsoft Entra Workload-ID integreert met de mogelijkheden die systeemeigen zijn voor Kubernetes om te federeren met externe id-providers.

Microsoft Entra Workload-ID gebruikt projectie van het tokenvolume van het serviceaccount (een serviceaccount) om pods in staat te stellen een Kubernetes-identiteit te gebruiken. Een Kubernetes-token wordt uitgegeven en OIDC-federatie stelt Kubernetes-toepassingen in staat om veilig toegang te krijgen tot Azure-resources met Microsoft Entra-id, op basis van geannoteerde serviceaccounts.

Microsoft Entra Workload-ID werkt vooral goed met de Azure Identity-clientbibliotheken of de msal-verzameling (Microsoft Authentication Library) samen met toepassingsregistratie. Uw workload kan gebruikmaken van een van deze bibliotheken om Azure-cloudresources naadloos te authenticeren en te benaderen.

Dit artikel helpt u inzicht te krijgen in Microsoft Entra Workload-ID en bekijkt de beschikbare opties voor het plannen van uw projectstrategie en potentiële migratie van door Microsoft Entra beheerde identiteit.

Notitie

U kunt serviceconnector gebruiken om bepaalde stappen automatisch te configureren. Zie ook: Wat is serviceconnector?

Afhankelijkheden

AKS ondersteunt Microsoft Entra Workload-ID op versie 1.22 en hoger.
Azure CLI versie 2.47.0 of hoger. Voer az --version deze uit om de versie te vinden en voer deze uit az upgrade om de versie te upgraden. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.

Azure Identity-clientbibliotheken

Kies in de Azure Identity-clientbibliotheken een van de volgende methoden:

Gebruik DefaultAzureCredential, dat probeert de WorkloadIdentityCredential te gebruiken.
Maak een ChainedTokenCredential exemplaar met WorkloadIdentityCredential.
Rechtstreeks gebruiken WorkloadIdentityCredential .

De volgende tabel bevat de minimale pakketversie die vereist is voor de clientbibliotheek van elk taalecosysteem.

Ecosysteem	Bibliotheek	Minimumversie
.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/identiteit	3.2.0
Python	azure-identity	1.13.0

In de volgende codevoorbeelden wordt DefaultAzureCredential gebruikgemaakt. Dit referentietype maakt gebruik van de omgevingsvariabelen die door de Azure Workload Identity muterende webhook worden geïnjecteerd om te verbinden met Azure Key Vault. Als u voorbeelden wilt bekijken met een van de andere benaderingen, raadpleegt u de koppelingen naar de ecosysteemspecifieke clientbibliotheek hierboven.

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)

De volgende clientbibliotheken zijn de minimale versie die vereist is.

Ecosysteem	Bibliotheek	Afbeelding	Voorbeeld	Heeft Windows
.NET	Microsoft Authentication Library-for-dotnet	`ghcr.io/azure/azure-workload-identity/msal-net:latest`	Koppeling	Ja
Ga	Microsoft Authentication Library for Go	`ghcr.io/azure/azure-workload-identity/msal-go:latest`	Koppeling	Ja
Java	Microsoft Authentication Library-for-java	`ghcr.io/azure/azure-workload-identity/msal-java:latest`	Koppeling	Nee
JavaScript	Microsoft Authentication Library-for-js	`ghcr.io/azure/azure-workload-identity/msal-node:latest`	Koppeling	Nee
Python	Microsoft Authentication Library-for-python	`ghcr.io/azure/azure-workload-identity/msal-python:latest`	Koppeling	Nee

Beperkingen

U kunt maximaal 20 federatieve identiteitsreferenties per beheerde identiteit hebben.
Het duurt een aantal seconden voordat de federatieve identiteitsreferentie wordt doorgegeven nadat deze in eerste instantie is toegevoegd.
De toevoeging van virtuele knooppunten, gebaseerd op het opensource-project Virtual Kubelet, wordt niet ondersteund.
Het maken van federatieve identiteitsreferenties wordt niet ondersteund voor door de gebruiker toegewezen beheerde identiteiten in deze regio's.

Hoe het werkt

In dit beveiligingsmodel fungeert het AKS-cluster als de tokenverlener. Microsoft Entra ID maakt gebruik van OpenID Connect om sleutels voor openbare ondertekening te detecteren en de echtheid van het serviceaccounttoken te verifiëren voordat u het uitwisselt voor een Microsoft Entra-token. Uw workload kan een serviceaccounttoken uitwisselen dat is geprojecteerd naar het volume voor een Microsoft Entra-token met behulp van de Azure Identity-clientbibliotheek of de Microsoft Authentication Library (MSAL).

In de volgende tabel worden de vereiste eindpunten voor OIDC-verleners voor Microsoft Entra Workload-ID beschreven:

Eindpunt	Beschrijving
`{IssuerURL}/.well-known/openid-configuration`	Ook wel bekend als het OIDC-detectiedocument. Dit bevat de metadata over de configuraties van de uitgever.
`{IssuerURL}/openid/v1/jwks`	Dit bevat de openbare ondertekeningssleutel(s) die door Microsoft Entra ID worden gebruikt om de echtheid van het serviceaccounttoken te verifiëren.

In het volgende diagram ziet u een overzicht van de verificatiereeks met behulp van OpenID Connect.

Automatische rotatie van het webhookcertificaat

Net als bij andere webhook-invoegtoepassingen wordt het certificaat geroteerd door de automatische rotatiebewerking van het clustercertificaat.

Serviceaccountlabels en aantekeningen

Microsoft Entra Workload-ID ondersteunt de volgende toewijzingen met betrekking tot een serviceaccount:

Een-op-een, waarbij een serviceaccount verwijst naar een Microsoft Entra-object.
Veel-op-een, waarbij meerdere serviceaccounts verwijzen naar hetzelfde Microsoft Entra-object.
Een-op-veel, waarbij een serviceaccount verwijst naar meerdere Microsoft Entra-objecten door de aantekening van de client-id te wijzigen. Zie Meerdere identiteiten federeren met een Kubernetes-serviceaccount voor meer informatie.

Notitie

Als de aantekeningen van het serviceaccount worden bijgewerkt, moet u de pod opnieuw starten om de wijzigingen van kracht te laten worden.

Als u een door Microsoft Entra-pod beheerde identiteit hebt gebruikt, kunt u een serviceaccount beschouwen als een Azure-beveiligingsprincipaal, behalve dat een serviceaccount deel uitmaakt van de Kubernetes-kern-API in plaats van een AANGEPASTe resourcedefinitie (CRD). In de volgende secties wordt een lijst met beschikbare labels en aantekeningen beschreven die kunnen worden gebruikt om het gedrag te configureren bij het uitwisselen van het serviceaccounttoken voor een Microsoft Entra-toegangstoken.

Aantekeningen voor serviceaccounts

Alle aantekeningen zijn optioneel. Als de aantekening niet is opgegeven, wordt de standaardwaarde gebruikt.

Annotatie	Beschrijving	Standaard
`azure.workload.identity/client-id`	Vertegenwoordigt de Microsoft Entra-toepassing client-ID die moet worden gebruikt met de pod.
`azure.workload.identity/tenant-id`	Vertegenwoordigt de Azure-tenant-id waar de De Microsoft Entra-toepassing is geregistreerd.	AZURE_TENANT_ID omgevingsvariabele geëxtraheerd van `azure-wi-webhook-config` ConfigMap.
`azure.workload.identity/service-account-token-expiration`	Vertegenwoordigt het `expirationSeconds` veld voor de geprojecteerde serviceaccounttoken. Het is een optioneel veld dat u configureert om downtime te voorkomen veroorzaakt door fouten tijdens het vernieuwen van het serviceaccounttoken. Het verlopen van het token van het Kubernetes-serviceaccount is niet gecorreleerd met Microsoft Entra-tokens. Microsoft Entra-tokens verlopen binnen 24 uur nadat ze zijn uitgegeven.	3600 Ondersteund bereik is 3600-86400.

Podlabels

Notitie

Voor toepassingen die workloadidentiteit gebruiken, is het vereist om het label azure.workload.identity/use: "true" toe te voegen aan de podspecificatie voor AKS om de workloadidentiteit te verplaatsen naar een scenario met fail close om een consistent en betrouwbaar gedrag te bieden voor pods die workloadidentiteit moeten gebruiken. Anders mislukken de pods nadat ze opnieuw zijn opgestart.

Etiket	Beschrijving	Aanbevolen waarde	Vereist
`azure.workload.identity/use`	Dit label is vereist in de sjabloonspecificatie voor pods. Alleen pods met dit label worden gemuteerd door de azure-workload-identity muterende toelatingswebhook om de specifieke omgevingsvariabelen van Azure en het geprojecteerde tokenvolume van het serviceaccount te injecteren.	true	Ja

Pod-aantekeningen

Alle aantekeningen zijn optioneel. Als de aantekening niet is opgegeven, wordt de standaardwaarde gebruikt.

Annotatie	Beschrijving	Standaard
`azure.workload.identity/service-account-token-expiration`	Vertegenwoordigt het `expirationSeconds`-veld voor het serviceaccount-token dat geprojecteerd is. Het is een optioneel veld dat u configureert om downtime te voorkomen die wordt veroorzaakt door fouten tijdens het vernieuwen van het serviceaccounttoken. Het verlopen van het token van het Kubernetes-serviceaccount is niet gecorreleerd met Microsoft Entra-tokens. Microsoft Entra-tokens verlopen binnen 24 uur nadat ze zijn uitgegeven. ¹	3600 Ondersteund bereik is 3600-86400.
`azure.workload.identity/skip-containers`	Vertegenwoordigt een door puntkomma's gescheiden lijst met containers om het toevoegen van een geprojecteerde serviceaccount-tokenvolume over te slaan. Bijvoorbeeld: `container1;container2`.	Standaard wordt het tokenvolume van het geprojecteerde serviceaccount toegevoegd aan alle containers als de pod is gelabeld met `azure.workload.identity/use: true`.
`azure.workload.identity/inject-proxy-sidecar`	Er wordt een proxy-initcontainer en een proxy-sidecar in de pod geïnjecteerd. De proxy-sidecar wordt gebruikt voor het onderscheppen van tokenaanvragen voor IMDS en het verkrijgen van een Microsoft Entra-token namens de gebruiker met federatieve identiteitsreferenties.	waar
`azure.workload.identity/proxy-sidecar-port`	Vertegenwoordigt de poort van de proxy-sidecar.	8000

¹ Heeft voorrang als de serviceaccount ook is aangemerkt.

Migreren naar Microsoft Entra Workload-ID

Op een cluster waarop al een door pod beheerde identiteit wordt uitgevoerd, kunt u deze configureren voor het gebruik van workloadidentiteit op twee manieren. Met de eerste optie kunt u dezelfde configuratie gebruiken die u hebt geïmplementeerd voor door pods beheerde identiteit. U kunt aantekeningen toevoegen aan het serviceaccount in de naamruimte met de identiteit om Microsoft Entra Workload-ID in te schakelen en de aantekeningen in de pods in te voeren.

De tweede optie is het herschrijven van uw toepassing voor het gebruik van de nieuwste versie van de Azure Identity-clientbibliotheek.

Om het migratieproces te stroomlijnen en te vereenvoudigen, hebben we een migratie-sidecar ontwikkeld waarmee de IMDS-transacties die uw toepassing uitvoert, worden geconverteerd naar OpenID Connect (OIDC). De migratiesidecar is niet bedoeld als een langetermijnoplossing, maar een manier om snel aan de slag te gaan met workloadidentiteit. Door de migratie-sidecar in uw toepassing uit te voeren, worden de IMDS-transacties van de toepassing naar OIDC doorverwezen. U kunt ook upgraden naar een ondersteunde versie van de Azure Identity-clientbibliotheek , die ondersteuning biedt voor OIDC-verificatie.

De volgende tabel bevat een overzicht van onze aanbevelingen voor migratie of implementatie voor de workloadidentiteit.

Scenario	Beschrijving
Nieuwe of bestaande clusterimplementatie voert een ondersteunde versie van de Azure Identity-clientbibliotheek uit	Er zijn geen migratiestappen vereist. Voorbeeldimplementatieresources: Workloadidentiteit implementeren en configureren op een nieuw cluster
Nieuwe of bestaande clusterimplementatie voert een niet-ondersteunde versie van de Azure Identity-clientbibliotheek uit	Werk containerafbeelding bij voor het gebruik van een ondersteunde versie van de Azure Identity SDK, of gebruik de migratiesidecar.

Volgende stappen

Zie Toepassingsverificatie moderniseren met workloadidentiteit voor meer informatie over het instellen van uw pod voor verificatie met behulp van een workloadidentiteit als migratieoptie.
Zie Een AKS-cluster implementeren en configureren met workloadidentiteit, waarmee u een Azure Kubernetes Service-cluster kunt implementeren en configureren om een voorbeeldtoepassing te configureren voor het gebruik van een workloadidentiteit.

Delen via

Microsoft Entra Workload-ID gebruiken met Azure Kubernetes Service (AKS)

Afhankelijkheden

Azure Identity-clientbibliotheken

Microsoft Authentication Library (MSAL)

Beperkingen

Hoe het werkt

Automatische rotatie van het webhookcertificaat

Serviceaccountlabels en aantekeningen

Aantekeningen voor serviceaccounts

Podlabels

Pod-aantekeningen

Migreren naar Microsoft Entra Workload-ID

Volgende stappen

Feedback

Aanvullende resources