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

Voor workloads die zijn geïmplementeerd op een AKS-cluster, zijn microsoft Entra-toepassingsreferenties of beheerde identiteiten vereist voor toegang tot met Microsoft Entra beveiligde resources, zoals Azure Key Vault en Microsoft Graph. De Microsoft Entra Workload-id kan worden geïntegreerd met de mogelijkheden die systeemeigen zijn voor Kubernetes om te federeren met externe id-providers, zodat u workloadidentiteiten kunt toewijzen aan uw workloads om andere services en resources te verifiëren en te openen.

Microsoft Entra Workload-id gebruikt Service Account Token Volume Projection zodat pods een Kubernetes-identiteit kunnen gebruiken. Er wordt een Kubernetes-token uitgegeven en de OIDC-federatie (OpenID Connect) stelt Kubernetes-toepassingen in staat om veilig toegang te krijgen tot Azure-resources met Microsoft Entra ID, op basis van geannoteerde serviceaccounts.

U kunt Microsoft Entra Workload-id gebruiken met Azure Identity-clientbibliotheken of de MSAL-verzameling (Microsoft Authentication Library), samen met toepassingsregistratie, om naadloos Azure-cloudresources te verifiëren en te openen.

Vereiste voorwaarden

Automatische AKS-clusters

Op automatische AKS-clusters worden de workloadidentiteit en de OIDC-clusterverlener vooraf geconfigureerd als onderdeel van de standaardinstellingen voor beveiliging van het cluster. Er is geen configuratie op clusterniveau vereist voordat u de workloadidentiteit in uw pods gebruikt. Ga rechtstreeks verder met het instellen van uw toepassing.

AKS Standard-clusters

• 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.
• U moet de workload-identiteit en de OIDC-uitgever op uw cluster inschakelen voordat uw pods workload-identiteit kunnen gebruiken. Zie Workloadidentiteit implementeren en configureren op een AKS-cluster.

Beperkingen

• U kunt maximaal 20 federatieve identiteitsreferenties per beheerde identiteit hebben.
• Het duurt enkele seconden voordat het federatieve identiteitsbewijs is verspreid nadat dit in eerste instantie is toegevoegd.
• De invoegtoepassing voor virtuele knooppunten , op basis van 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.

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 .

Wanneer u tokens aanvraagt met WorkloadIdentityCredential, geeft u bereiken op in de Microsoft Entra ID v2-indeling <resource>/.default, zoals https://management.azure.com/.default. Een onbewerkte resource-URI, zoals https://management.azure.com/, kan mislukken omdat de workloadidentiteit gebruikmaakt van het Microsoft Entra v2-tokeneindpunt in plaats van de IMDS-stroom resource die wordt gebruikt door beheerde identiteit. Zie Een token ophalen voor meer informatie over hoe scopes werken in het v2-tokeneindpunt.

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

Codevoorbeelden voor Azure Identity-clientbibliotheek

De volgende codevoorbeelden gebruiken de DefaultAzureCredential. Dit referentietype maakt gebruik van de omgevingsvariabelen die worden geïnjecteerd door de muterende workloadidentiteit webhook om authenticatie met Azure Key Vault uit te voeren. Raadpleeg de ecosysteemspecifieke clientbibliotheken om voorbeelden te bekijken met een van de andere benaderingen.

Vervang <key-vault-url> en <secret-name> door de juiste waarden voor uw Key Vault en geheim.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("<key-vault-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("<key-vault-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("<key-vault-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("<key-vault-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["<key-vault-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('<key-vault-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:

Hoe het werkt

In dit beveiligingsmodel fungeert het AKS-cluster als de tokenverlener. Microsoft Entra ID maakt gebruik van OIDC 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 MSAL.

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

In het volgende diagram wordt de verificatiereeks samengevat met behulp van OIDC:

Automatische rotatie van Webhook-certificaat

Net als andere webhook-add-ons roteert de bewerking voor automatische rotatie van het clustercertificaat het webhookcertificaat van de workload-identiteit.

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 annotatie van de client-id te wijzigen. Zie Meerdere identiteiten federeren met een Kubernetes-serviceaccount voor meer informatie.

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 u kunt gebruiken 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.

Podlabels

Pod-aantekeningen

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

Identiteitsbindingen en directe federatie gebruiken in dezelfde workload

Identiteitsbindingen zijn een preview-functie die de workloadidentiteit uitbreidt ter ondersteuning van grootschalige AKS-omgevingen. In plaats van een federatieve identiteitsreferentie (FIC) te maken voor elk cluster, kunnen met identiteitsbindingen meerdere clusters één door de gebruiker toegewezen beheerde identiteit delen via één FIC. Indien ingeschakeld, routeert AKS podtokenaanvragen via een webhook voor de id-bindingsproxy die tokenuitwisseling verwerkt namens de workload.

Een geprojecteerd serviceaccounttoken heeft één doelgroep. Wanneer identiteitsbindingen zijn ingeschakeld, stelt de webhook voor identiteitsbinding het standaardtoken in waarnaar wordt verwezen door AZURE_FEDERATED_TOKEN_FILE de doelgroep api://AKSIdentityBinding, die door de identiteitsbindingsproxy wordt gebruikt.

Directe Microsoft Entra Workload-id federatie (zonder identiteitsbindingen) vereist een token met de doelgroepapi://AzureADTokenExchange. Het hergebruiken van het bestand met het identiteitsbindingstoken voor directe federatie mislukt met AADSTS700212 omdat de doelgroepclaim van de federatieve identiteitsreferentie niet overeenkomt met de doelgroepclaim van het token.

Als u identiteitsbindingen wilt gebruiken voor één beheerde identiteit en directe federatie voor een andere in dezelfde workload, projecteert u een tweede serviceaccounttoken met de api://AzureADTokenExchange doelgroep en wijst u de directe federatiecode aan op dat bestand:

apiVersion: v1
kind: Pod
metadata:
  name: workload-with-ib-and-direct-fic
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: workload-sa
  containers:
  - name: app
    image: <image>
    volumeMounts:
    - name: direct-fic-token
      mountPath: /var/run/secrets/direct-fic
      readOnly: true
    env:
    - name: DIRECT_FIC_TOKEN_FILE
      value: /var/run/secrets/direct-fic/token
  volumes:
  - name: direct-fic-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          audience: api://AzureADTokenExchange
          expirationSeconds: 3600

Gebruik AZURE_FEDERATED_TOKEN_FILE voor de identiteitskoppelingsstroom en het aangepaste tokenbestand, zoals DIRECT_FIC_TOKEN_FILE, voor de stroom voor direct gefedereerde identiteitsreferenties.

Migreren naar Microsoft Entra Workload-id

U kunt clusters configureren waarop al een door pod beheerde identiteit wordt uitgevoerd om de Workload-id van Microsoft Entra te gebruiken op een van de volgende twee manieren:

• Gebruik dezelfde configuratie 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.
• Herschrijf uw toepassing om de nieuwste versie van de Azure Identity-clientbibliotheek te gebruiken.

Om het migratieproces te stroomlijnen en te vereenvoudigen, hebben we een migratie-sidecar ontwikkeld die de IMDS-transacties (Instance Metadata Service) converteert die uw toepassing uitvoert naar OIDC. De migratie-sidecar is niet bedoeld als een langetermijnoplossing, maar een manier om snel aan de slag te gaan met de Microsoft Entra Workload-id. 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 uw AKS-cluster:

Verwante inhoud

• Zie Toepassingsverificatie moderniseren met Microsoft Entra Workload-ID om te leren hoe u uw pod kunt instellen voor verificatie door gebruik te maken van een workloadidentiteit als een migratieoptie.
• Zie Een AKS-cluster implementeren en configureren met De Workload-id van Microsoft Entra, waarmee u een cluster kunt implementeren en een voorbeeldtoepassing kunt configureren voor het gebruik van een workloadidentiteit.
• Zie What is Azure Kubernetes Service Automatic? voor meer informatie over de vooraf geconfigureerde beveiligingsstandaarden van AKS Automatic, waaronder workloadidentiteit.