Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Résumé
Utilisez cet article pour résoudre l’erreur LinkedAuthorizationFailed lorsque vous créez ou déployez un cluster Azure Kubernetes Service (AKS). En suivant ces étapes, vous pouvez effectuer l’opération avec succès.
Symptômes
Lorsque vous essayez de créer un cluster AKS, vous recevez le message d’erreur suivant :
La réconciliation du VNet a échoué.
Détails : Échec de la nouvelle tentative de VNetReconciler :
Catégorie : ClientError ; SubCode : LinkedAuthorizationFailed ;
Dépendance : Microsoft.Network/virtualNetworks ; ErreurOriginale : Code="LinkedAuthorizationFailed"
Message="Le client 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb' avec l'ID d'objet '123456789-1234-1234-1234-1234567890987' est autorisé à effectuer l'action 'Microsoft.Network/virtualNetworks/write' sur l'étendue '/subscriptions/<subscription-id-guid>/resourceGroups/MC_MyRG_westeurope/providers/Microsoft.Network/virtualNetworks/aks-vnet' ; toutefois, il n'est pas autorisé à effectuer l'action 'Microsoft.Network/ddosProtectionPlans/join/action' sur la ou les étendues liées '/subscriptions/<subscription-id-guid>/resourcegroups/ddos-protection-plan-rg/providers/microsoft.network/ddosprotectionplans/upmddosprotectionplan' ou la ou les étendues liées ne sont pas valides.";
AKSTeam : Mise en réseau, retriable : false.
La cause
Un principal de service n’a pas l’autorisation d’utiliser une ressource requise pour la création du cluster.
Solution
Accordez aux autorisations du principal de service pour utiliser la ressource mentionnée dans le message d’erreur. L’exemple de sortie de la section « Symptômes » fournit les informations suivantes.
| Élément | Valeur |
|---|---|
| Principal de service | aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb |
| Ressource | /subscriptions/<subscription-id-guid>/resourcegroups/ddos-protection-plan-rg/providers/microsoft.network/ddosprotectionplans/upmddosprotectionplans |
| Opération | Microsoft.Network/ddosProtectionPlans/join/action |
Pour plus d’informations sur l’octroi d’autorisations au principal de service, consultez Affecter des rôles Azure à l’aide du Portail Azure.
Plus d’informations
Si les attributions de rôles apparaissent correctes, mais que la création du cluster échoue toujours, vérifiez la propagation de l’attribution de rôle, confirmez les autorisations dans l’étendue de la ressource liée, inspectez les journaux d’activité pour les échecs d’autorisation et vérifiez que la ressource référencée existe toujours et est accessible à partir de l’abonnement cible et du groupe de ressources. Passez en revue l’opération exacte indiquée dans l’erreur (par exemple) Microsoft.Network/ddosProtectionPlans/join/actionet confirmez que l’identité dispose de cette autorisation sur la ressource liée.
Si l’autorisation requise semble être accordée, mais que le déploiement échoue toujours avec LinkedAuthorizationFailed, vérifiez l’identité et le périmètre concernés lors de la vérification de l’autorisation. Passez en revue le message d’erreur complet pour identifier :
ID client ou objet effectuant l’opération.
Étendue de ressource liée référencée dans l’erreur.
Action spécifique qui est refusée (par exemple, Microsoft.Network/ddosProtectionPlans/join/action).
Vérifiez que l’identité utilisée par le déploiement AKS (principal de service ou identité managée) a l’attribution de rôle requise sur la ressource principale et toutes les ressources liées référencées dans le message d’erreur. Vérifiez également que l’affectation de rôle existe dans l’étendue appropriée et que les autorisations héritées s’appliquent bien. Pour les scénarios complexes impliquant des ressources dans différents groupes de ressources ou abonnements, passez en revue les journaux d’activité Azure et les attributions de rôles afin de déterminer à quel niveau l’autorisation échoue avant de relancer la création du cluster.