Service Principal
An identity used by applications, CI/CD pipelines, or scripts to authenticate to Azure and access resources under defined RBAC permissions, distinct from a user identity and typically authenticated via a client secret or certificate.
Service Principal
A Service Principal is how non-human callers — pipelines, apps, scripts — authenticate to Azure, with its own scoped permissions separate from any individual employee's account.
Why It Matters in Production
CRED's GitHub Actions pipeline authenticates to Azure using a dedicated service principal scoped only to the resource groups it deploys into, so a leaked pipeline secret can't be used to access unrelated production data.
az ad sp create-for-rbac --name cred-cicd-sp \ --role Contributor --scopes /subscriptions/<sub-id>/resourceGroups/cred-prod-rgSecurityPrefer Managed Identities over service principals with client secrets wherever possible — there's no secret to leak or rotate.
Frequently Asked Questions
Why does Azure need a separate Service Principal concept instead of just using a user account?
A Service Principal is the local, tenant-scoped identity created from an Azure AD App Registration — it's what actually gets assigned RBAC roles on subscriptions and resource groups. Using a human user's credentials for a pipeline is fragile (password resets, MFA prompts, offboarding breaks the pipeline) and violates least-privilege since a person's account usually has broader access than the automation needs. Service Principals are also what Terraform's azurerm provider commonly authenticates as in CI/CD.
What's a common mistake when securing an Azure Service Principal in CI/CD?
Using a client secret with a long or no expiry and storing it as a plain pipeline variable instead of in a secrets store like Azure Key Vault. Secrets get logged, leaked, or forgotten until they silently expire and break a deploy. Prefer certificate-based auth or, better, Workload Identity Federation (OIDC) from GitHub Actions/Azure DevOps, which eliminates the stored secret entirely by trusting short-lived tokens issued at pipeline run time.