az role assignment list service principal

Assigning Service Principals to Groups and Roles with the Azure CLI

The more I use Azure the more often I find myself needing to assign various managed identities / service principals to various groups and roles, and while that can be done in the Portal, it's cumbersome and I'd prefer to automate it.

So in this post I'll sharing a few Azure CLI commands that should prove useful whenever you're configuring Service Principals.

Getting a service principal's object id

Suppose you know the name of the service principal, but not the "object id", which is required for assigning it to groups and roles. You can use a filter with the az ad sp list command to find that service principal and then a query to pick out just the object id.

Note that you should avoid trying to use the query parameter to find the matching name, as that will likely not find it as it only applies to the first page of results .

Note that the object id is different from the app id. If you do need the app id for any reason you just need to change the query parameter:

Adding to a group

Suppose we want to add the service principal to a group. We need the group id to do that, and if we need to look it up, we can do so with the az ad group list command and using a filter .

Then the az ad group member add command allows us to add the object id of our service principal to the group.

Creating a role assignment

If we want to create a role assignment, then as well as knowing the user we're assigning the role to and the name of the role, we also need to provide a " scope " for that to apply to. This is typically a long / delimited path to an Azure resource. So for a KeyVault it might look like this:

You can of course construct this string yourself, but actually this is quite often just the "ID" of the resource as returned by the Azure CLI. So we could get the above value with the following command:

And now that we have the scope, we can simply use the az role assignment create to assign the role to our service principal, and we can pass the role name directly (in this example it's "Key Vault Administrator"):

Hope this proves useful to you.

• CreatingAServicePrincipal

If you just want to get started asap with a service principal and azure with a client secret and permissive RBAC settings, then just run the following commands (redacted as required)

Why use a Service Principal anyways

When it comes to running some commands adhoc off the command line, a human user account based on a user principal account is fine. But for any serious use case, this would not qualify as a sustainable devops practice. Typically this is done by calling the az login command from a terminal which invokes a web-based login process in the background. For automation, a service principal account is required to run tasks such as:

• Continuous Integration tasks (eg blob storage access)
• Continuous Deployment tasks (eg deployment of a vm)
• Infrastructure as Code Deployments (eg using terraform)
• Running scheduled tasks
• Accessing Azure Key vault or Azure Blob storage from a running application in application code using the Azure SDKs

Anatomy of a Service Principal

A service principal does not exist in isolation. In fact, a service principal is a 'security principal' or identity that represents an active directory application in a given tenant. By default, a security principal will be created in the default tenant along with the application object. As azure active directory is multi-tenant, further service principals can be created for additional tenants should the requirement arise.

Service Principal and authentication

Authentication with a service principal can be through using

• A client secret
• A client certificate (X.509 self-signed certificate)

Generally, I prefer the creation of an azure service principal with a client certificate which has been self-signed.

From a security perspective, it is vital to keep both secrets and certificates secure. This can be done by encrypting the data with mozilla sops .

Azure Terraform Provider

Terraform is a highly declarative language for defining infrastructure and I normally prefer it for creating all kinds of infrastructure.

Terraform still requires a service principal to get started - chicken and egg situation.

The service principal for the azuread_service_principal terraform module requires the User Account Administrator role. From a security perspective, using such a highly priveleged service principal requires careful scrutiny.

Creating an Azure Application

Prerequisites.

• Azure CLI - The installation instructions of az cli on ubuntu can be found here

Login with a user principal

This will return the following information revealing the user, default tenant and default subscription information.

Ensure the Correct Azure Subscription is selected

If you need to use a specific subscription other than the default one when logged in, it can be set as follows

Note: You can check what subscriptions are available by running az account list .

Create the azure application

Docs for az ad app create

The extract below shows some of the important fields from the http response including the appId and objectId .

Note: You can check what apps are already created by running

Creating the Service Principal

The service principal is created next and associated with the previously created app. The appId or objectId can be used to assign the service principal

Docs for az ad spn create

Extract from the json response:

Credentials creation with a client secret

So far no credentials have been created for the service principal. Let's take a look...

Docs for az ad sp credential list

The response is an empty list which confirms roles are not yet assigned

Create new credentials with a client secret

The response is as follows:

Once these credentials are returned, you will need to store them somewhere secure for later retrieval, ideally, in an encrypted format.

Running the following command again will reveal the credentials:

Note: If you are a user of terraform azure provider , the credentials above correspond to the following naming in terraform:

Credentials creation with a client certificate

Creating a certificate using the azure cli.

The easy way to do this is to have the azure cli create a certificate for you. Let's append new credentials by creating a public cert and private key with the azure cli.

Note: With the --append argument, the previous secret based credentials will not be overridden. Omit --append if you want to use a client certificate only and override previous credentials.

The output is as follows:

The value for fileWithCertAndPrivateKey contains the path to the public certificate and the private key. This file should be stored somewhere safely and ideally in an encrypted format. It is the key to the kingdom. Although, we will be reducing the dominion of that kingdom later by employing RBAC and setting roles on the service principal.

Creating a certificate with your own certificate authority

You can also create your own certificate and private key using your own certificate authority for creating the service principal credentials.

In this guide, I will create a certificate authority to create the azure service principal certificate. If you already have your own certificate authority then you can skip this step. Basically, this means using your own PKI (public key infrastructure).

You can keep the files ca.pem and ca-key.pem for further uses of as your certificate authority. The ca-key.pem is the private key ancd should be kept very safe, ideally in an encrypted format.

The next step is to create the new service principal private key and certificate

As a result of running the last command, a private key file cert-key.pem and public cert cert.pem will be generated. Be sure to store these files away, in a safe location, ideally encrypted. Azure requires having these two files concatenated together to login as a service principal. The login process is demonstrated later

Now we are ready to create the service principal with the self-signed certificate as follows:

Given the complexity of creating your own public key infrastructure and generating the certs, it is probably easier to just create a certificate using the azure cli as outlined earlier .

Roles assignment and RBAC

Role Based Access Control allows devops and software engineers to create service principals following the least privilege principle. Here are two ways to approach assigning roles to an azure service principal:

• Assign built-in roles
• Assign a custom role definition

After the service principal has been associated to the app in the default tenant, no roles have yet been assigned to the service principal. Roles are the way in which access control works in Azure. Let's take a look at the roles assigned so far.

Docs for az role assignment list

Assigning a built-in role to a service principal

The Contributor built-in role is highly permissive - avoid using it when possible. It would be better to assign the minimal roles necessary. For example, if an application only requires read access to an azure blob storage container, then the Storage Blob Data Reader is all that is required. Assigning multiple restrictive built-in roles is also possible and better than applying the highly permissive Contributor role.

The --scope argument allows one to reduce the access levels of the service principal even further. It can be restricted to specific subscription(s) and even more fine grained to specific resource group(s).

By using a sensible combination of roles and scopes, the overall security of operations in the cloud is enhanced. In the unlikely event that a service principal becomes comprimised, the potential for malicious activitty is reduced to the smallest range of resources.

Assigning a custom role definition to a service principal

An entirely custom role can be built up from scratch and assigned to a service principal. This is a very powerful approach to RBAC for a service principal because it gives the cloud operator fine-grained control of what permissions are granted.

Once the credentials creation step and rbac assignment steps are complete, the service principal is then ready to use and it can be tested to verify that it is working correctly.

While still logged in as a user principal, you can get set some of the variables in the terminal before running an azure logout.

At this stage, logout with your user principal account.

Logging in with a client secret

Logging in with an azure generated client cert.

When you ran the az cli command to create credentials to a client cert as outlined in above , the json response included a key pair "fileWithCertAndPrivateKey": "<path_to_pem>" . This file path contains the private key and public certificate in a single file.

To login, just pass the file path in the password field of the az login command as follows:

Logging in with a self-signed client cert

Assuming that cert-key.pem is the private key and cert.pem is the public certificate, azure requires that those certs are concatenated into a single file and the path of the newly created concatenated cert file passed in the password field for login.

Now that you have your service principal setup, it's time to use it for some terraform automation.

View service principal assignments (permissions) in Azure

Published February 1, 2021 in azure .

At work we recently moved our DNS hosting to Azure DNS in order to simplify our hosting and benefiting from existing RBAC in Azure AD. One benefit of the move is that we could generate limited API keys for clients to be able to use ACME DNS-01 challenge for certificate validation.

We have been using acme.sh and it has documentation how to create a limited service principal for DNS-01 validation.

This works really well but what if you want to view the permission the service principal has?

The enterprise application blade in Azure AD does not list what resources the application (service principal) has but if you go to each resource IAM page you can see if the service principal has access.

However in Azure CLI can list out what the service principal has access to.

First find the appId of the service principal you want to check (in my case AcmeDnsValidator):

Then you can use find the role assignment (permission) of the service principal:

Here you can see this service principal has access to DNS zone example.com in resource group rg-resourcegroupname using the role defined ‘DNS TXT Contributor’.

To view the role definition you use:

Azure Service Principals In Depth

An application’s service principal holding permission keys to the power of Azure.

What is a Service Principal?

From the official documentation :

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons, it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.

In my own words, a service principal is an identity that represents an application for either (1) authentication and authorization with Azure resources or (2) authentication with other services that integrate with Azure AD.

Service principals are a specific type of security principal , which are entities that can be authenticated with Azure.

It is an identity

A service principal is essentially an identity which represents a non-human users, analogous to email for human users.

It is for applications, hosted services, and automated tools

A service principal is meant for use by non-human users (applications, microservices, functions, scripts, etc.). It should not be used by human users to authenticate and represent themselves.

It only has access to Azure roles assigned to it

A service principal can be assigned suitable Azure roles at different hierarchical levels, e.g. subscription, management group, resource. This allows service principals to abide by the principle of least privilege.

Pedantically, there are actually a few types of service principals :

• Application
• Managed identity

This rest of the blog post only concerns with the Application service principal type. Generally, when the “service principal” term is used, it usually refers to the Application service principal type.

Create a Service Principal

Just as we need to authenticate ourselves with an SMTP server to access our email, service principals need to authenticate with Azure to gain authorization to specific roles and permissions in Azure.

There are two ways to do this:

Password-based authentication

Using this mode, a random password is created by Azure for you. Optionally, you may specify a resource name for the service principal. You can set the role assignment at time of creation, or do it later.

The service principal password is only shown to you at this time. Store it somewhere safe. If you lose it, you can reset its credentials like follows:

Certificate-based authentication

Using this mode, you will authenticate with Azure using a private key certificate.

The simplest way to get started is to get Azure to generate a self-signed certificate for you:

You can also generate your own private key certificate (PEM, CER, or DER) and provide it to Azure to create the service principal. The invoker of this service principal will also need the private key as proof of authentication to Azure.

Or with a path to the certificate:

You can also upload or generate a certificate in Azure Key Vault and provide it to the service principal via the --cert and --keyvault parameter:

An example console output for service principal creation is as follows:

Here is a concrete example output when creating a password-based service principal:

Do note on the APP_ID value, which we will need for role assignment next. This value is also commonly known as the CLIENT_ID , with the corresponding password known as the CLIENT_SECRET .

Manage Service Principal Roles

Creating a service principal by itself doesn’t give you any authorization to do anything in Azure. You need to first assign it some roles.

Assign a role:

Delete a role:

To view the currently assigned roles:

Signing in with a Service Principal

Essentially, you will need either a password or a private key to authenticate with a service principal.

You may log in using the service principal to try it out:

To log in using a certificate (private key):

Subsequently you (or the CLI script you are running) are then able to create and manage resources as this service principal.

Usually though, instead of using the CLI, you will want to authenticate the service principal using the Azure SDK for your application’s programming language.

For example, using the Azure SDK for Java, you can do the same thing as above in Java code:

Or if your secret is stored in Azure Key Vault:

But maybe YAGNI? (You Ain’t Gonna Need It)

If your application is hosted within say, an Azure VM, you should actually not use a service principal (application type) but instead try to use the following secretless methods (out of scope of this blog post):

• Default Azure credential
• Managed Identity credential

Using the above two methods, the application does not need to manage and secure the password or certificate, which is definitely a boost for security. So first consider if you can do away with service principals altogether.

For applications hosted in Azure Kubernetes Service (AKS), then you’ll probably need a service principal to represent the pods or containers, because there is no Azure identity representation at the pod or container level.

That’s it for this blog post. Happy to hear your thoughts via [email protected] .

Check out some of my books and courses!

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Manage service principal roles

• 2 contributors

In order to restrict access to your Azure resources, you can use a service principal to manage role assignments. Each role provides different permissions allowed by the user when accessing Azure resources. This step in the tutorial explains how to create and remove service principal roles.

The Azure CLI has the following commands to manage role assignments:

• az role assignment list
• az role assignment create
• az role assignment delete

Create or remove a role assignment

The Contributor role has full permissions to read and write to an Azure account. The Reader role is more restrictive with read-only access. Always use the principle of least privilege. For a complete list of available roles in Azure RBAC, see Azure built-in roles .

Adding a role doesn't restrict previously assigned permissions. This example adds the Reader role and removes the Contributor role:

Output Console:

How to get a value for the scope parameter

One question you might have is "How do I know the --scope parameter value?" The answer is to find and copy the Resource ID of the Azure resource your service principal needs to access. This information is usually found in the Azure portal's Properties or Endpoints page of each resource. Here are common --scope examples, but rely on your Resource ID for an actual format and value .

For more scope examples, see Understand scope for Azure RBAC .

Verify changes

The changes can be verified by listing the assigned roles:

You can also go into the Azure portal and manually assign the role to the service principal from the Access control (IAM) menu. For more examples on listing role assignments, see List Azure role assignments using Azure CLI .

Now that you've learned how to manage your service principal roles, proceed to the next step to learn how to use service principals to create a resource.

Create a resource using service principal

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

• Career Model
• Proactive Mentorship
• Productivity
• Review Model
• Work:Life Balance
• 3D Printing
• Announcements
• Conferences

How to find all the Azure Built-In Roles for Azure RBAC with Azure CLI, PowerShell, Docs, or AzAdvertizer

Here are a bunch of ways you can find which roles are built into Azure. This will come in super handy when you need to assign a role to a service principal or user with Azure CLI commands like this:

• Query the big honking json
• Query all, but only return Name and Id in a nice table
• Filter by name contains:

This one filters for roles with “Map” in the name:

Azure PowerShell

https://docs.microsoft.com/en-us/powershell/module/az.resources/get-azroledefinition?view=azps-3.8.0

This page has all the built in roles: https://docs.microsoft.com/azure/role-based-access-control/built-in-roles

AzAdvertizer

Just found this site today by Julian Hayward. It’s a great way to find roles

https://www.azadvertizer.net/azrolesadvertizer_all.html

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

az role assignment list/create fail when listing/creating by Service Principal name #27257

rzunigams commented Aug 24, 2023

yonzhan commented Aug 24, 2023

Sorry, something went wrong.

rzunigams commented Aug 29, 2023 • edited

jiasli commented Sep 28, 2023

No branches or pull requests