Get the AZURE_CREDENTIALS of a Service Principal

I have already created my service principal.

Using GitHub I need to complete all parameters below. My question is where and how can we find each one?

AZURE_CREDENTIALS :
{
  "clientId": "XXX",
  "clientSecret": "XXX",
  "subscriptionId": "XXX",
  "tenantId": "XXX",
  "activeDirectoryEndpointUrl": "XXX",
  "resourceManagerEndpointUrl": "XXX",
  "activeDirectoryGraphResourceId": "XXX",
  "sqlManagementEndpointUrl": "XXX",
  "galleryEndpointUrl": "XXX",
  "managementEndpointUrl": "XXX"
}

I've already seen in the documentation that we can generate a JSON file for a new principal service using CLI Azure:

az ad sp create-for-rbac `
         --name "myApp" --role contributor `
         --scopes /subscriptions/8baa642d-5109-4f1c-b935-401e5b215078/resourceGroups/rg-ai-recommender `
         --sdk-auth

But I want to use the existing Service Principal.

Solution

You can run the command multiple times.

If you run it again, a message will appear stating something like:

az ad sp create-for-rbac --name TestPrincipal --role Contributor --sdk-auth
Found an existing application instance of "[existingId]". We will patch it
Creating 'Contributor' role assignment under scope '/subscriptions/[guid]'
  Role assignment already exists.

The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
'name' property in the output is deprecated and will be removed in the future. Use 'appId' instead.
{
  "clientId": "[existingId]",
  "clientSecret": "[aNewSecret]",
  "subscriptionId": "[subscriptionid]",
  // all the other properties
}

Of course, this will invalidate the credentials you're using in the other repositories, so you should update those also.

Recovering the secret isn't possible because it's a secret.

This way you can use the same service principal in multiple repositories.

Do keep in mind, it might be a more secure strategy to create new service principals for different services/deployments, so you can make the assignments of roles as granular as possible. But that's not what your question is about.