web-dev-qa-db-fra.com

Comment puis-je trouver le secret principal du service de mon cluster AKS?

D'accord, donc j'ai foiré, j'ai accidentellement couru az ad sp reset-credentials par rapport au principal du service sous lequel notre cluster AKS fonctionne. Et maintenant, nous obtenons des erreurs comme:

Erreur lors de la création de l'équilibreur de charge (réessayera): erreur lors de l'obtention de LB pour le test de service/admin-api: Azure.BearerAuthorizer # WithAuthorization: échec de l'actualisation du jeton pour la demande à https://management.Azure.com/subscriptions/ ****/resourceGroups/MC _ ****/providers/Microsoft.Network/loadBalancers? api-version = 2017-09-01: StatusCode = 0 - Erreur d'origine: adal: échec de la demande d'actualisation. Code d'état = '401'. Corps de réponse: {"error": "invalid_client", "error_description": "AADSTS70002: Erreur lors de la validation des informations d'identification. AADSTS50012: Un secret client non valide est fourni.\R\nTrace ID: ****\r\nCorrelation ID: *** *\r\nTimestamp: 2018-08-23 12: 01: 33Z "," error_codes ": [70002,50012]," timestamp ":" 2018-08-23 12: 01: 33Z "," trace_id ":" **** "," correlation_id ":" **** "}

et

Impossible d'extraire l'image "****. Azurecr.io/****:****": erreur rpc: code = Unknown desc = Réponse d'erreur du démon: Obtenez https: //****.azurecr. io/v2/****/manifestes/****: non autorisé: authentification requise

Alors maintenant, je veux trouver le secret client d'origine que le principal de service utilise, afin que je puisse l'ajouter à nouveau comme clé au principal de service. C'est la seule solution à laquelle je peux penser autre que la recréation de l'ensemble du cluster.

Des idées?

azureazure-active-directoryazure-container-serviceazure-kubernetes
11
PeterH

Celui qui vient sur ce problème a une solution mise à jour de Microsoft

https://docs.Microsoft.com/en-us/Azure/aks/update-credentials#update-aks-cluster-with-new-credentials

Ils mentionnent également (ce qui n'est pas évident) que: Par défaut, les clusters AKS sont créés avec un principal de service qui a un délai d'expiration d'un an.

De plus, À partir d'Azure CLI 2.0.68, le paramètre --password pour créer un principal de service avec un mot de passe défini par l'utilisateur n'est plus pris en charge pour empêcher l'utilisation accidentelle de mots de passe faibles. donc la solution initiale pour changer le mot de passe principal du service ne fonctionne plus.

2
Iulian Paraian

Au final, la solution était assez simple.

  • Dans le portail Azure, accédez au groupe de ressources nommé MC_<resourcegroup>_<aksName>_<region>.
  • Cliquez sur l'une des ressources du type "Machine virtuelle".
  • Faites défiler jusqu'à "Exécuter la commande"

Run command

  • Choisissez "RunShellScript"
  • Entrer cat /etc/kubernetes/Azure.json et cliquez sur "Exécuter"

La commande renverra le contenu du fichier JSON. La propriété dont vous avez besoin est aadClientSecret

6
PeterH

C'est une chose ennuyeuse que tu veux faire. Pour votre problème, vous ne pouvez pas extraire l'image sans authentification.

Tout d'abord, vous devez connaître le principal de service de votre registre de conteneurs. Vous pouvez le faire dans le portail Azure et accédez au panneau de registre, puis vous pouvez trouver le principal du service comme ceci:

enter image description here

Ou vous pouvez utiliser la commande Azure CLI pour trouver l'ID de registre comme ceci:

az acr show --resource-group groupName --name registryName --query id --output tsv

Utilisez ensuite la commande pour trouver l'ID principal du service comme ceci:

az role assignment list --scope registryID

Vous pouvez sélectionner le principal de service que vous souhaitez.

Ensuite, vous obtiendrez tous les secrets avec la commande kubectl get secrets et kubectl get secrets secretName -o yaml pour obtenir le jeton du secret. Analysez ensuite un par un pour vérifier si le nom d'utilisateur est le même que l'ID principal du service. Vous pouvez utiliser des outils tels que JWT pour analyser le jeton secret. Le résultat sera comme ceci:

enter image description here

Si le nom d'utilisateur est le même que l'ID principal du service que vous trouvez, c'est le secret que vous voulez. Cette étape est un problème. Vous devriez vérifier le secret un par un ou vous aurez un meilleur moyen de le vérifier.

Soit dit en passant, il semble que vous ne puissiez voir le mot de passe du principal du service qu'une fois lorsque vous le créez. L'Azure ne vous montrera plus. Mais si vous créez le secret Kubernetes, le mot de passe y est stocké.

0
Charles Xu