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

Artikel
11/17/2023

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 maakt gebruik van serviceaccounttokenvolumeprojectie, waardoor pods een Kubernetes-identiteit (dat wil gezegd een serviceaccount) kunnen 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 en de MSAL-verzameling (Microsoft Authentication Library) als u toepassingsregistratie gebruikt. Uw workload kan elk van deze bibliotheken gebruiken om azure-cloudresources naadloos te verifiëren en te openen.

In dit artikel vindt u meer informatie over deze nieuwe verificatiefunctie en bekijkt u de beschikbare opties voor het plannen van uw projectstrategie en mogelijke migratie van door Microsoft Entra beheerde identiteit.

Notitie

In plaats van alle stappen handmatig te configureren, is er een andere implementatie met de naam Service Verbinding maken or waarmee u bepaalde stappen automatisch kunt configureren. Zie ook: Wat is Service Verbinding maken or?

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, waarmee wordt geprobeerd de WorkloadIdentityCredential.
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 zijn geïnjecteerd om de webhook te dempen voor verificatie met 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)

De volgende clientbibliotheken zijn de minimale versie die vereist is.

Ecosysteem	Bibliotheek	Afbeelding	Opmerking	Heeft Windows
.NET	Microsoft Authentication Library-for-dotnet	`ghcr.io/azure/azure-workload-identity/msal-net:latest`	Koppeling	Ja
Go	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 slechts 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.
Virtuele knooppunten worden niet ondersteund op basis van het opensource-project Virtual Kubelet.
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 tokenverlener. Microsoft Entra ID maakt gebruik van OpenID Verbinding maken om sleutels voor openbare ondertekening te detecteren en de echtheid van het serviceaccounttoken te verifiëren voordat het wordt uitgewisseld 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.

Diagram van het AKS-workloadbeveiligingsmodel voor identiteiten.

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 metagegevens over de configuraties van de verlener.
`{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 Verbinding maken.

Diagram van de OIDC-verificatiereeks van de AKS-workloadidentiteit.

Automatische rotatie van 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-identiteit, behalve dat een serviceaccount deel uitmaakt van de kubernetes-API, in plaats van een aangepaste resourcedefinitie (CRD). Hieronder 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 projected service account token. 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 gedempt door de azure-workload-identity waarmee de toegangswebhook wordt gedempt om de specifieke Omgevingsvariabelen van Azure en het geprojecteerde tokenvolume van het serviceaccount te injecteren.	true	Ja

Podaantekeningen

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 projected serviceaccounttoken. 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 projected serviceaccounttokenvolume over te slaan. Bijvoorbeeld: `container1;container2`.	Standaard wordt het tokenvolume van het geprojecteerde serviceaccount toegevoegd aan alle containers als het serviceaccount is gelabeld met `azure.workload.identity/use: true`.
`azure.workload.identity/inject-proxy-sidecar`	Hiermee injecteert u een init-container en proxy-sidecar in de pod. 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.	true
`azure.workload.identity/proxy-sidecar-port`	Vertegenwoordigt de poort van de proxy-sidecar.	8000

¹ Heeft voorrang als het serviceaccount ook een aantekening heeft.

Migreren naar workloadidentiteit

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 vandaag hebt geïmplementeerd voor door pods beheerde identiteit. U hoeft alleen aantekeningen te maken bij het serviceaccount in de naamruimte met de identiteit en stelt workloadidentiteit in staat om de aantekeningen in de pods te injecteren.

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 Verbinding maken (OIDC). De sidecar van de migratie 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 uitgevoerd. 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. Voorbeeld van implementatiebronnen: - Workloadidentiteit implementeren en configureren op een nieuw cluster - Zelfstudie: Een workloadidentiteit gebruiken met een toepassing in AKS
Nieuwe of bestaande clusterimplementatie voert een niet-ondersteunde versie van de Azure Identity-clientbibliotheek uit	Werk containerinstallatiekopieën bij om een ondersteunde versie van de Azure Identity SDK te gebruiken of gebruik de migratie-sidecar.

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 de zelfstudie Een workloadidentiteit gebruiken met een toepassing in Azure Kubernetes Service (AKS), waarmee u een Azure Kubernetes Service-cluster kunt implementeren en een voorbeeldtoepassing kunt configureren voor het gebruik van een workloadidentiteit.

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 webhookcertificaat

Serviceaccountlabels en aantekeningen

Aantekeningen voor serviceaccounts

Podlabels

Podaantekeningen

Migreren naar workloadidentiteit

Volgende stappen

Aanvullende resources