Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How can I find the service principal secret of my AKS cluster?

Okay, so I messed up, I accidentally ran az ad sp reset-credentials against the Service Principal that our AKS cluster runs under. And now we are getting errors like:

Error creating load balancer (will retry): error getting LB for service test/admin-api: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/****/resourceGroups/MC_****/providers/Microsoft.Network/loadBalancers?api-version=2017-09-01: StatusCode=0 -- Original Error: adal: Refresh request failed. Status Code = '401'. Response body: {"error":"invalid_client","error_description":"AADSTS70002: Error validating credentials. AADSTS50012: Invalid client secret is provided.\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":"****"}

and

Failed to pull image "****.azurecr.io/****:****": rpc error: code = Unknown desc = Error response from daemon: Get https://****.azurecr.io/v2/****/manifests/****: unauthorized: authentication required

So now I want to find the original client secret that the Service Principal uses, so that I can re-add that as a key to the Service Principal. That's the only solution I can think of other than recreating the entire cluster.

Any ideas?

like image 711
PeterH Avatar asked Aug 23 '18 12:08

PeterH


2 Answers

In the end the solution was quite simple.

  • In the Azure portal, navigate to the resource group named MC_<resourcegroup>_<aksName>_<region>.
  • Click one of the resources of the type "Virtual machine".
  • Scroll down to "Run command"

Run command

  • Choose "RunShellScript"
  • Enter cat /etc/kubernetes/azure.json and click "Run"

The command will return the contents of the JSON file. The property you need is aadClientSecret

like image 129
PeterH Avatar answered Sep 28 '22 10:09

PeterH


Whoever comes over this issue there's an updated solution from Microsoft

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

They also mention (something that's not obvious) that: By default, AKS clusters are created with a service principal that has a one-year expiration time.

Also, As of Azure CLI 2.0.68, the --password parameter to create a service principal with a user-defined password is no longer supported to prevent the accidental use of weak passwords. so the initial solution to change the service principal password doesn't work anymore.

like image 35
Iulian Paraian Avatar answered Sep 28 '22 12:09

Iulian Paraian