Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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:
- Recuperare la definizione del ruolo corrente.
- Aggiungere l'autorizzazione applicabile
certificatesigningrequests/nodeclient/actionalla proprietàDataActionsdel ruolo. - Verificare che tutte le richieste di firma del certificato esistenti e le autorizzazioni di rilevamento API rimangano invariate.
- Aggiornare la definizione del ruolo personalizzata.
- Attendere la propagazione dell'aggiornamento di Azure RBAC.
Convalidare l'aggiornamento del ruolo
Dopo aver aggiornato un ruolo personalizzato coinvolto:
- Recuperare la definizione del ruolo e verificare che l'autorizzazione applicabile
certificatesigningrequests/nodeclient/actionvenga visualizzata inDataActions. - Verificare che tutte le richieste di firma del certificato esistenti e le autorizzazioni di individuazione API rimangano invariate.
- In un ambiente di test eseguire un test di bootstrap esterno end-to-end e verificare che il nodo raggiunga lo
Readystato. - 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.