Creating an Identity for Service Principals in Azure
Creating a Service Principal in Azure
An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Service Principals allow you to provision an account that only has enough permissions and scope to run a task within a predefined set of Azure resources. Think of it as a 'user identity' (login and password or certificate) with a specific role, and tightly controlled permissions to access your resources. It only needs to be able to do specific things, unlike a general user identity.
Using a Service Principal improves security if you only grant it the minimum permission levels needed to perform its specific tasks. Service Principals with locked down permissions are easier to provision, monitor and de-provision if something goes wrong. Service Principals rely on a corresponding Azure Active Directory application.
In order to use a Service Principal, you will need the following:
An Application ID Uniform Resource Identifier, also known as a URI, is used to identify a logical or physical resource.
A Secret key
And the tenant ID, also known as our Active Directory ID
The URI and Secret key will be used to authenticate in place of a user name and password.
Check Azure Active Directory Permissions
App Registrations Permissions
The App registrations setting must me set to Yes in order for any user within the AD tenant to register an app.
If the App registrations setting is set to No, only administrative users can register an app.
Administrator Access
If your account is assigned to the User role, but the App registrations setting from the preceding steps is limited to administrative users, ask your administrator to either assign you to an administrative role, or to enable users to register apps.
Check Azure subscription permissions
In your Azure subscription, your account must have Microsoft.Authorization/*/Write access to assign an AD app to a role. This action is granted through the Owner role or User Access Administrator role. If your account is assigned to the Contributor role, you do not have adequate permission. You receive an error when attempting to assign the service principal to a role.
Request Permissions
If you do not have adequate permissions, ask your subscription administrator to add you to the User Access Administrator role.
Create an Azure Active Directory Application
Name - Choose a user-facing display name for your application.
Supported account types - Choose can use the application or access the API.
Redirect URI - Enter a URI to return the authentication response to after successfully authenticating the user.
Once the configuration is complete, click Register.
Get Application ID and Client Secret
When programmatically logging in, you need the ID for your application and an authentication key.
To get those values, use the following steps:
Description - Provide a description for your client secret.
Expires - Choose how long that your client secret should be valid for.
Best Practices
From a best practices standpoint, it is not suggested to have a secret that never expires.
After saving the key, the Value along with the Secret ID is displayed on the Certificates and secrets page.
Get Tenant ID
When programmatically logging in, you need to pass the tenant ID with your authentication request.
Assign application to role
To access resources in your subscription, you must assign the application to a role. Decide which role represents the right permissions for the application. To learn about the available roles, see RBAC: Built in Roles.
You can set the scope at the level of the subscription, resource group, or resource. Permissions are inherited to lower levels of scope. For example, adding an application to the Reader role for a resource group means it can read the resource group and any resources it contains.
Subscription
To assign at the subscription level, select Subscriptions from the Azure Management Portal and follow the same steps listed below.