#Principle app proicing password
To log in via Azure CLI, it’s a one line command:Īz login -service-principal -username APP_ID -password PASSWORD -tenant TENANT_ID Now that you have your Service Principal and permissions assigned, how do you use them? Signing into via PowerShell or Azure CLI can be quite quickly achieved. Of course, there are times when you need to grant Contributor level to your Service Principals at the subscription level for certain tasks. Where possible I try and restrict rights to resource group level and not directly at the subscription level. My recommendation would be to remove the contributor role assignment and add the correct level. So, this is something to be aware of, when using Azure CLI. As I mentioned at the start of this post that isn’t great best practice.
The Azure CLI command to create a Service Principal is shorted and on creation the randomly generated password is displayed on screen.Īz ad sp create-for-rbac -name ServicePrincipalDisplayNameīy default, when you a create a Service Principal via Azure CLI or PowerShell it grants it Contributor access to your Azure subscription. $UnsecureSecret = ::PtrToStringAuto($BSTR) # Export the random password that was generated on creation $sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName # Create the Service Principal, generates a random password
#Principle app proicing code
When you create a Service Principal via PowerShell you do not get a copy of the password displayed, so you need to input a couple of lines of code to retrieve the password, as you can see in the code below. I have a small script that creates my Service Principal and it generates a random password to go with the Service Principal so that I have it for those password-based authentication occasions.
#Principle app proicing full
Only those that really need full administrator rights should have them! )Ĭreating a Service Principal can be done in a number of ways, through the portal, with PowerShell or Azure CLI. They shouldn’t have more permissions than they need. When you create automation service accounts or Service Principals you should really think about what rights you give them. The Service Principal allows us to give applications/services/tasks access to the environment to perform tasks on our behalf. Within Azure when we want to automate tasks we have to use something similar, and it’s called a Service Principal. Using service accounts allowed us to avoid embedding our own network usernames and password into these automation tasks. The service account was a bit like a user account with a username and password, and it often had access to local and network resources to perform these automation tasks. One thing that was often essential to these automation tasks was a service account. When I worked with on-prem IT infrastructure I was always keen to automate parts as much as possible, whether that was setting up a scheduled task to stop and start services on temperamental servers or automating the patching of the servers.
0 kommentar(er)
