Aggiornare i ruoli di Azure personalizzati per il bootstrap del certificato del nodo esterno

A partire dal 30 novembre 2026, Servizio Azure Kubernetes (AKS) richiede una DataAction dedicata del controllo degli accessi in base al ruolo di Azure (Azure RBAC) per autorizzare il rilascio del certificato client kubelet.

Important

Aggiornare i ruoli personalizzati di Azure interessati prima del 30 novembre 2026. In caso contrario, i nuovi nodi esterni potrebbero non riuscire a unirsi al cluster AKS e quelli già esistenti potrebbero non riuscire a rinnovare i certificati client di kubelet.

Questo requisito si applica ai ruoli di Azure personalizzati usati per il rinnovo del certificato client kubelet o bootstrap del nodo esterno, incluse le integrazioni AKS Stretch. I nodi gestiti da AKS non dovrebbero essere interessati.

In precedenza, l'azione sui dati più ampia certificatesigningrequests/write autorizzava anche il rilascio dei certificati client di kubelet. AKS sta separando queste autorizzazioni per impedire alle entità di sicurezza con accesso in scrittura generico alle richieste di firma dei certificati di ottenere certificati che consentano loro di autenticarsi come nodi Kubernetes.

Determinare se un ruolo personalizzato è interessato

Un ruolo personalizzato è interessato se viene usato per una delle operazioni seguenti:

  • Bootstrap del nodo esterno.
  • Rinnovo del certificato client Kubelet per un nodo esterno.

Se un ruolo personalizzato viene usato solo per le operazioni generali di richiesta di firma del certificato, non è necessario aggiungere la nuova autorizzazione.

Esaminare gli ID ruolo nella notifica di integrità dei servizi di Azure o nell'inventario dei ruoli e determinare il modo in cui viene usato ogni ruolo. Conservare la richiesta di firma del certificato esistente di ogni ruolo interessato e le autorizzazioni di individuazione delle API.

Aggiungere il DataAction richiesto

Aggiungere DataAction che corrisponde all'endpoint della risorsa usato dall'integrazione:

Endpoint delle risorse Azione sui dati obbligatoria
Cluster gestito Microsoft.ContainerService/managedClusters/certificates.k8s.io/certificatesigningrequests/nodeclient/action
Hub della flotta Microsoft.ContainerService/fleets/certificates.k8s.io/certificatesigningrequests/nodeclient/action
Membro della flotta Microsoft.ContainerService/fleets/members/certificates.k8s.io/certificatesigningrequests/nodeclient/action
AI Manager Microsoft.ContainerService/aiManagers/certificates.k8s.io/certificatesigningrequests/nodeclient/action

Ad esempio, un ruolo personalizzato usato per il bootstrap del nodo esterno tramite un endpoint del cluster gestito include le autorizzazioni seguenti:

{
  "DataActions": [
    "Microsoft.ContainerService/managedClusters/certificates.k8s.io/certificatesigningrequests/write",
    "Microsoft.ContainerService/managedClusters/certificates.k8s.io/certificatesigningrequests/read",
    "Microsoft.ContainerService/managedClusters/certificates.k8s.io/certificatesigningrequests/delete",
    "Microsoft.ContainerService/managedClusters/apis/certificates.k8s.io/read",
    "Microsoft.ContainerService/managedClusters/apis/certificates.k8s.io/v1beta1/read",
    "Microsoft.ContainerService/managedClusters/certificates.k8s.io/certificatesigningrequests/nodeclient/action"
  ]
}

Per l'accesso a Fleet hub, Fleet member o AI Manager, utilizzare il percorso della risorsa corrispondente indicato nella tabella precedente.

Per aggiornare il ruolo coinvolto:

  1. Recuperare la definizione del ruolo corrente.
  2. Aggiungere l'autorizzazione applicabilecertificatesigningrequests/nodeclient/action alla proprietàDataActions del ruolo.
  3. Verificare che tutte le richieste di firma del certificato esistenti e le autorizzazioni di rilevamento API rimangano invariate.
  4. Aggiornare la definizione del ruolo personalizzata.
  5. Attendere la propagazione dell'aggiornamento di Azure RBAC.

Convalidare l'aggiornamento del ruolo

Dopo aver aggiornato un ruolo personalizzato coinvolto:

  1. Recuperare la definizione del ruolo e verificare che l'autorizzazione applicabile certificatesigningrequests/nodeclient/action venga visualizzata in DataActions.
  2. Verificare che tutte le richieste di firma del certificato esistenti e le autorizzazioni di individuazione API rimangano invariate.
  3. In un ambiente di test eseguire un test di bootstrap esterno end-to-end e verificare che il nodo raggiunga lo Ready stato.
  4. Per un'integrazione esistente, verificare che il certificato client kubelet possa essere rinnovato correttamente tramite il normale processo di convalida.

Attendere circa un'ora per il test bootstrap end-to-end del nodo esterno. Il tempo totale necessario può variare a seconda del processo di gestione delle modifiche dell'organizzazione e del numero di ruoli da aggiornare.

Passaggi successivi