In this blog post, I’ll guide you through the process of creating a service principal using PowerShell, including steps for retrieving secrets and leveraging federated credentials as well as certificate-based authentication for secure, secretless authentication in workflows like GitHub Actions. Managing programmatic access to your Azure resources securely is essential, and a service principal is a key part of achieving that. ## Prerequisites Before we start, ensure you have: - PowerShell installed on your machine. - The Az PowerShell module installed. - An Azure account with sufficient permissions to create service principals and assign roles. ## Creating a Service Principal Using PowerShell To create a service principal with PowerShell, start by running the following command: ``` $sp = New-AzADServicePrincipal -DisplayName "Quickstart App Service API" -Role "Contributor" -Scope "/subscriptions/" ``` - Replace the DisplayName with the name you want for your service principal. - Replace `` with your Azure subscription ID. This command will create the service principal, assigning it the Contributor role at the subscription level, and return details such as the application ID (client ID) and tenant ID. ## Retrieving the Client Secret After Creation After creating your service principal, you can retrieve the client secret with a simple command: ``` $sp.PasswordCredentials.SecretText ``` This command outputs the client secret value, which is crucial for authenticating the service principal. Remember to securely store this secret, as it will not be retrievable later. ## Using Federated Credentials for GitHub Actions Workflows To avoid managing client secrets directly, you can use federated credentials for secure, passwordless authentication, especially useful in CI/CD workflows. Federated credentials allow a service principal to authenticate with Azure Active Directory through an external identity provider, such as GitHub. Here's how you can configure federated credentials for your service principal: ``` $params = @{ ApplicationObjectId = (Get-AzADApplication -DisplayName "Quickstart App Service API").Id Audience = "api://AzureADTokenExchange" Issuer = "https://token.actions.githubusercontent.com" Name = "OIDC" Subject = "repo:/:environment:" } New-AzADAppFederatedCredential @params ``` Replace the placeholders: - `` with your GitHub organization name. - `` with your GitHub repository name. - `` with the specific environment in GitHub Actions (e.g., production, staging This configuration allows GitHub Actions workflows to authenticate without storing a client secret, enhancing security by leveraging OpenID Connect (OIDC) for token exchange. To make the federated credential setup even more flexible, you can specify different types of entities as the subject in the federated credentials, such as GitHub branches, pull requests, or tags. This flexibility allows you to restrict or target specific actions in your GitHub repository, enhancing control over which workflows can authenticate with Azure. **Branch-Based Authentication**: The subject pattern `repo:/:ref:refs/heads/` restricts authentication to workflows triggered on a specific branch. **Pull Request-Based Authentication**: Using `repo:/:pull_request` enables authentication specifically for pull requests within the repository, useful for CI/CD testing workflows. **Tag-Based Authentication**: The pattern `repo:/:ref:refs/tags/` allows authentication for workflows triggered by specific tags, often used for versioned deployments. ## Certificate-Based Authentication This approach offers a secure way to authenticate Azure applications and workflows, especially when compared to traditional methods like password-based authentication. Certificates can be easily regenerated when expired and work well for automation scenarios. ### Generate a Self-Signed Certificate The first step is to create a self-signed certificate in your local certificate store. Below is the PowerShell snippet to achieve this: ``` $certconf = @{ CertStoreLocation = "cert:\CurrentUser\My" Subject = "CN=myWorkflow" KeySpec = "KeyExchange" } # Generate a self-signed certificate $cert = New-SelfSignedCertificate @certconf ``` This script creates a certificate with the subject CN=myWorkflow. The certificate is stored in the CurrentUser store under `My`. ### Convert Certificate to Base64 Azure requires the certificate in Base64 format. You can achieve this using the following command: ``` # Convert certificate to Base64 for storing in the service principal $keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData()) ``` This extracts the raw data from the certificate and encodes it as a Base64 string. ### Create the Service Principal With the Base64 certificate ready, configure and create the Service Principal: ``` # Configure Service Principal $spconf = @{ DisplayName = "myWorkflow" CertValue = $keyValue EndDate = $cert.NotAfter StartDate = $cert.NotBefore } # Create the Azure AD Service Principal $sp = New-AzADServicePrincipal @spconf ``` This command creates a Service Principal with the Base64-encoded certificate as its authentication method. ### Assign Roles to the Service Principal ``` New-AzRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $sp.AppId -Scope "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RG/providers/Microsoft.ContainerRegistry/registries/YOUR_ACR" ``` This script grants the Contributor role to the Service Principal on a specific Azure Container Registry. ### Full Script {% embed https://gist.github.com/Latzox/ac739896931053168a5355d620c217c9.js %} By following these steps, you’ll be able to create service principals in Azure using PowerShell and set up secretless authentication for secure, automated workflows in environments like GitHub Actions. Using federated credentials can streamline your automation workflows, making them both efficient and secure.

latzox

Using PowerShell to Create Service Principals for RBAC

Join Our Newsletter. No Spam, Only the good stuff.