A service principal is an application identity stored in Microsoft Entra ID. Software uses it to authenticate when accessing Azure resources, such as a database, instead of acting as a human user. section 2.1.3
A service principal can sign in with a password or certificate. Protect either credential: anyone who obtains it can impersonate the application and gain access to the Azure environment. Managed identities avoid credential management where supported. section 2.1.4 section 2.14
Configure a service principal around the access it actually needs:
- Create the application identity, optionally assigning access to Azure resources during creation. section 2.1.4
- Assign an Azure RBAC role and scope. The service principal is the authorization “who”; the role defines allowed actions over the selected scope. section 2.3.2
- Store generated credentials outside code and source control, such as protected CI/CD secrets. section 2.1.4 section 11.3.1
CI/CD deployment identity
A GitHub Actions workflow can use a service principal to enable Defender for Cloud plans across Azure subscriptions. Create the identity with a Contributor role scoped to the target subscription, then configure the CI/CD platform with its generated authentication output. OpenID Connect is an alternative that avoids storing secrets in the platform. section 11.3.1
Listing 11.1 Creating a service principal in Microsoft Entra ID
az ad sp create-for-rbac –display-name "githubActionsApp" #1 --role Contributor #2 --scopes /subscriptions/ bh24babd-fb35-4348-8ec0-b9a058b4722e #3 --sdk-auth #4 #1 The display name of the service principal #2 The role that specifies the necessary permissions #3 The scope on which the role assignment is applied #4 The output result compatible with the Azure SDK auth file
This Azure CLI command creates a service principal, assigns the Contributor role at a subscription scope, and formats output for Azure SDK authentication. section 11.3.1
