Client ID and Secret are exposed / known to the consumer of the Service Principal.Client ID and Secret are exposed / known to the creator of the Service Principal.First, Someone needs to create the Service Principal objects, which could be a security risk.While this seems all fair from a security perspective, since we are not literally using the Azure administrative accounts (former service account concepts, remember…) anymore, there are also a few challenges involved in using SPs: NOTE: The best recommendation I can give, is to store the Service Principal credentials in a safe way, like using Azure Key Vault, instead of a clear-text Notepad document or Terraform.tf fileĪnd in a somehow similar way, you would use the same concept from about any other third party solution, keeping in mind that the technical parameter field names might differ a bit from what the Azure CLI command provides as output. Tenant ID = tenant from the Azure CLI outputĪnd using a Terraform deployment template file (or terraform.tfvars variable file) as an example, would use this information like this: Terraform subscription service principal vars.
#No one respects my secret identity password#
Service Principal Key = password from the Azure CLI output.Service Principal Id = appId from the Azure CLI output.Subscription Name = can be found from your Azure Portal / Subscriptions make sure you use the exact name as is listed.Subscription Id = can be found from the Azure CLI under “/subscriptions/xxxxxx-xxxx-xxxx” format.Where you just need to copy the correct information in the corresponding parameter fields: Let me show you the command syntax out of Azure CLI to achieve this: az ad sp create-for-rbac -name "pdtdevblogsp"Ĭopy this information aside in the example of an Azure DevOps Service Connection, this information would be used as follows:
Typical use cases where you would rely on a Service Principal is for example when running Terraform IAC (Infrastructure as Code) deployments, or when using Azure DevOps for example, where you define a Service Connection from DevOps Pipelines to Azure or basically any other 3rd party application requiring an authentication token to connect to Azure resources.Īn Azure Service Principal can be created using “any” traditional way like the Azure Portal, Azure PowerShell, Rest API or Azure CLI.
(to be 100% correct on this statement, there is actually a preview available since mid Oct 2020, allowing RBAC KeyVault access as well – check this article for more details). There is one major exception to this RBAC rule, and that is Azure Key Vault, which can be extended by using Key Vault Access Policies to define permissions, instead of Azure RBAC roles. The Service Principals’ access can be restricted by assigning Azure RBAC roles so that they can access the specific set of resources only. In essence, by using a Service Principal, you avoid creating “fake users” (we would call them service account in on-premises Active Directory…) in Azure AD to manage authentication when you need to access Azure Resources. Most relevant to Service Principal, is the Enterprise apps according to the formal definition, a service principal is “…An application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service or automation tool, when an organization is using Azure Active Directory…”