Condividi tramite

Creare un provider OpenID Connect nel servizio Azure Kubernetes

  • Articolo

OpenID Connect (OIDC) estende il protocollo di autorizzazione OAuth 2.0 da usare come un altro protocollo di autenticazione rilasciato da Microsoft Entra ID. È possibile usare OIDC per abilitare l'accesso Single Sign-On (SSO) tra le applicazioni abilitate per OAuth, nel cluster del servizio Azure Kubernetes usando un token di sicurezza denominato token ID. Con il cluster del servizio Azure Kubernetes è possibile abilitare l'autorità di certificazione OpenID Connect (OIDC), che consente a Microsoft Entra ID o a un’altra piattaforma di gestione degli accessi e identità del provider di servizi cloud di individuare le chiavi di firma pubblica del server API.

Il servizio Azure Kubernetes cambia automaticamente e periodicamente la chiave. Se non si vuole aspettare, puoi cambiare la chiave manualmente e immediatamente. La durata massima del token emesso dal provider OIDC è di un giorno.

Avviso

Abilitando l’emissione dell’OIDC in un cluster esistente, si modifica l’emittente del token dell'account del servizio attuale e si ottiene un nuovo valore che può causare tempi di inattività, dato che si riavvia il server API. Se i pod dell'applicazione che usano un token di servizio rimangono in uno stato di errore dopo l'abilitazione dell'OIDC, si consiglia di riavviare manualmente i pod.

Questo articolo mostra come creare, aggiornare e gestire l'autorità emittente OIDC per il cluster.

Importante

Dopo aver abilitato l'autorità emittente OIDC nel cluster, la disabilitazione non è supportata.

Il token deve essere aggiornato periodicamente. Se si usa l'SDK, la rotazione è automatica. In caso contrario, è necessario aggiornare manualmente il token ogni 24 ore.

Prerequisiti

  • Interfaccia della riga di comando di Azure versione 2.42.0 o successiva. Eseguire az --version per trovare la versione in uso. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
  • Il servizio Azure Kubernetes supporta l'autorità emittente OIDC nella versione 1.22 e successive.

Creare un cluster del servizio Azure Kubernetes con l’autorità di certificazione OIDC

È possibile creare un cluster del servizio Azure Kubernetes usando il comando az aks create con il parametro --enable-oidc-issuer per abilitare l'autorità di certificazione OIDC. L'esempio seguente crea un cluster chiamato myAKSCluster con un nodo nel myResourceGroup:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 1 \
    --enable-oidc-issuer \
    --generate-ssh-keys

Aggiornare un cluster del servizio Azure Kubernetes con l'autorità emittente OIDC

È possibile aggiornare un cluster del servizio Azure Kubernetes usando il comando az aks update con il parametro --enable-oidc-issuer per abilitare l'autorità emittente OIDC. L'esempio seguente aggiorna un cluster chiamato myAKSCluster:

az aks update --resource-group myResourceGroup --name myAKSCluster --enable-oidc-issuer

Visualizzare l'URL dell'autorità emittente OIDC

Per ottenere l'URL dell'autorità di certificazione OIDC, eseguire il comando az aks show. Sostituire i valori predefiniti con il nome del cluster e il nome del gruppo di risorse.

az aks show --name myAKScluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv

Per impostazione predefinita, l'autorità di certificazione è impostata per usare l'URL di base https://{region}.oic.prod-aks.azure.com, dove il valore per {region} corrisponde al luogo dove viene distribuito il cluster del servizio Azure Kubernetes.

Cambiare la chiave OIDC

Per cambiare la chiave OIDC, eseguire il comando az aks oidc-issuer. Sostituire i valori predefiniti con il nome del cluster e il nome del gruppo di risorse.

az aks oidc-issuer rotate-signing-keys --name myAKSCluster --resource-group myResourceGroup

Importante

Dopo aver cambiato la chiave, la chiave precedente (key1) scade dopo 24 ore. Sia la chiave precedente (key1) che la nuova chiave (key2) sono valide per 24 ore dopo la rotazione. Se si vuole invalidare immediatamente la chiave precedente (key1), è necessario cambiare la chiave OIDC due volte e riavviare i pod usando token dell'account del servizio proiettati. Con questo processo, key2 e key3 sono validi, mentre key1 non è valido.

Controllare le chiavi OIDC

Ottenere l'URL dell'autorità emittente OIDC

Per ottenere l'URL dell'autorità di certificazione OIDC, eseguire il comando az aks show. Sostituire i valori predefiniti con il nome del cluster e il nome del gruppo di risorse.

az aks show --name myAKScluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv

L'output sarà simile al seguente:

https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/

Per impostazione predefinita, l'autorità di certificazione è impostata per usare l'URL di base https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, dove il valore per {region} corrisponde al luogo dove viene distribuito il cluster del servizio Azure Kubernetes. Il valore {uuid} rappresenta la chiave OIDC, che è un GUID generato in modo casuale per ogni cluster, il quale non è modificabile.

Ottenere il documento di individuazione

Per ottenere il documento di individuazione, copiare l'URL https://(OIDC issuer URL).well-known/openid-configuration e aprirlo nel browser.

L'output sarà simile al seguente:

{
  "issuer": "https://eastus.oic.prod-aks.azure.com/ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0/00000000-0000-0000-0000-000000000000/",
  "jwks_uri": "https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/openid/v1/jwks",
  "response_types_supported": [
    "id_token"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ]
}

Ottenere il documento JWK Set

Per ottenere il documento JWK Set, copiare il jwks_uri dal documento di individuazione e incollarlo nella barra degli indirizzi del browser.

L'output sarà simile al seguente:

{
  "keys": [
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "xxx",
      "alg": "RS256",
      "n": "xxxx",
      "e": "AQAB"
    },
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "xxx",
      "alg": "RS256",
      "n": "xxxx",
      "e": "AQAB"
    }
  ]
}

Durante il cambiamento delle chiavi, nel documento di individuazione è presente un'altra chiave.

Passaggi successivi