Kinga
Posted on October 10, 2023
If you are using Azure DevOps pipelines with Service Connections, you may have noticed a mysterious blue dot next to your service connection name
There's also a notification on top of the Service connection page:
which opens a Create an Azure Resource Manager service connection using workload identity federation documentation.
Why is it important
Azure Resource Manager Service Connections that use Service Principal are using Service Principal Id and either key (a secret) or certificate to authenticate.
Managed Identity authentication, on the other hand, is for self hosted agents.
I never understood why can't we use Managed Identity for Microsoft hosted agents, since Azure DevOps runs on Azure anyway. 🤔 It seems that someone at Microsoft was of the same opinion.
So here we are, it seems we can finally (mind it's still in preview) get rid of these secrets and certificates =)
New Azure Service Connection
I went ahead and created a new service connection using Workload Identity federation (automatic)
Details page looks very familiar, there's a link to Manage service connection roles and to Manage Service Principal
Manage Service Principal
Let's see what happens here... Manage Service Principal redirects me to Azure Portal. It's an App Registration page
After clicking on Managed application in local directory link, I'm redirected to the Enterprise Application page
Grant API Permissions
Perfect, granting access to the identity used by the pipeline is therefore exactly the same, as to any other service using Managed Identity.
Let's say that my pipeline will create some items in a SPO list. I'm using PnP.PowerShell, so both: Graph and SharePoint API permissions are required. Obviously, I'm scoping access using Sites.Selected.
What you need to note down here, is the information displayed on the Enterprise Application page. The Application Id is the same in both cases, but you need the correct Object Id.
$appId ="3fxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx6d"
$objId = "bdxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx34"
Grant API Permissions
Use MsGraph PowerShell to grant Sites.Selected API permissions
$tenantID = "{tenant-id}"
$objId = "bdxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx34" #from Enterprise Application page
$appId = "3fxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx6d"
Connect-MgGraph -TenantId $tenantID -Scopes "AppRoleAssignment.ReadWrite.All", "Application.Read.All"
# Get Service Principal
$sp = Get-MgServicePrincipal -ServicePrincipalId $objId
### STEP 1: GRANT API PERMISSIONS TO MANAGED IDENTITY
#Retrieve the Azure AD Service Principal instance for the Microsoft Graph (00000003-0000-0000-c000-000000000000) or SharePoint Online (00000003-0000-0ff1-ce00-000000000000).
$servicePrincipal_Graph = Get-MgServicePrincipal -Filter "DisplayName eq 'Microsoft Graph'"
$servicePrincipal_SPO = Get-MgServicePrincipal -Filter "DisplayName eq 'Office 365 SharePoint Online'"
#Get AppRole Id for Sites.Selected
$appRole_GraphId = ($servicePrincipal_Graph.AppRoles | Where-Object { $_.AllowedMemberTypes -eq "Application" -and $_.Value -eq "Sites.Selected" }).Id
$appRole_SPOId = ($servicePrincipal_SPO.AppRoles | Where-Object { $_.AllowedMemberTypes -eq "Application" -and $_.Value -eq "Sites.Selected" }).Id
# Grant API Permissions
$graphParams = @{
principalId = $sp.Id
resourceId = $servicePrincipal_Graph.Id
appRoleId = $appRole_GraphId
}
$spoParams=@{
principalId = $sp.Id
resourceId = $servicePrincipal_SPO.Id
appRoleId = $appRole_SPOId
}
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -BodyParameter $graphParams
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -BodyParameter $spoParams
#Quick check if everything went well
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id
Let's double check. Both, the App Registration page and the Enterprise App page show that API permissions have been granted:
Grant permissions to a SPO site
Next, grant permissions to the SPO site. This script is the continuation of the example above and is using $sp object to retrieve the Service Principal Display Name
### STEP 2: GRANT SPO ACCESS TO MANAGED IDENTITY
$tenantName = "{tenant-name}.sharepoint.com"
$spoSiteId = $tenantName + ":/sites/" + $siteName + ":"
$appRole = "write"
$application = @{
id = $appId
displayName = $sp.DisplayName
}
Connect-MgGraph -Scope Sites.FullControl.All
New-MgSitePermission -SiteId $spoSiteId -Roles $appRole -GrantedToIdentities @{ Application = $application }
The pipeline
So far everything looks really familiar. Let's look into the pipeline now.
I want to connect to the SP site using PnP.PowerShell. This time however, I won't be using service principal id or certificate. I want to use the Managed Identity from the pipeline's context.
This requires an additional step. First, I need to retrieve the token from the Azure Context, and then I'm using the token to connect to SPO.
$azAccessToken = Get-AzAccessToken -ResourceUrl $url
$conn = Connect-PnPOnline -Url "$url/sites/$(siteName)" -AccessToken $azAccessToken.Token -ReturnConnection
$web = Get-PnPWeb -Connection $conn
This example pipeline has some extra try/catch. You wouldn't do it productively, but it will help you to see where any potential errors occur =)
variables:
- name: tenantName
value: "contoso"
- name: siteName
value: "siteName"
steps:
- task: AzurePowerShell@5
name: ConnectPnpOnline
inputs:
azureSubscription: DEV_Connection
azurePowerShellVersion: latestVersion
ScriptType: InlineScript
Inline: |
$url = "https://$(tenantName).sharepoint.com"
Write-Host "##[debug]Connecting to $url/sites/$(siteName)"
Write-Host "##[group]Install/Import PS modules"
Install-Module PnP.PowerShell -Scope "CurrentUser" -Verbose -AllowClobber -Force
Write-Host "##[endgroup]"
try {
$azAccessToken = Get-AzAccessToken -ResourceUrl $url
$conn = Connect-PnPOnline -Url "$url/sites/$(siteName)" -AccessToken $azAccessToken.Token -ReturnConnection
Write-Host "##[debug]Get-PnPConnection"
Write-Host $conn.Url
}
catch {
Write-Host "##[error] 1 (Connect-PnPOnline -AccessToken): $($_.Exception.Message)"
}
try {
Write-Host "##[debug]Get-PnPWeb"
$web = Get-PnPWeb -Connection $conn
Write-Host $web.Title
}
catch {
Write-Host "##[error] 2 (Get-PnPWeb): $($_.Exception.Message)"
}
displayName: A couple of tests
The script above grants Managed Identity write permissions, so let's try to create an item. Make sure you have a list named "Test"
variables:
- name: tenantName
value: "contoso"
- name: siteName
value: "siteName"
steps:
- task: AzurePowerShell@5
name: DeploySPFx
inputs:
azureSubscription: DEV_Connection
azurePowerShellVersion: latestVersion
ScriptType: InlineScript
Inline: |
# Write-Host "##[group]Install/Import PS modules"
# Install-Module PnP.PowerShell -Scope "CurrentUser" -Verbose -AllowClobber -Force
# Write-Host "##[endgroup]"
$url = "https://$(tenantName).sharepoint.com"
try {
$azAccessToken = Get-AzAccessToken -ResourceUrl $url
$conn = Connect-PnPOnline -Url "$url/sites/$(siteName)" -AccessToken $azAccessToken.Token -ReturnConnection
Add-PnPListItem -List "test" -Values @{"Title"="$(Build.BuildId)"} -Connection $conn
}
catch {
Write-Host "##[error]$($_.Exception.Message)"
}
displayName: Add item
It works! =)
So cool! 🤩 Now we can get rid of the secrets and certificates
Why not Connect-PnPOnline -ManagedIdentity?
Currently, the Connect-PnPOnline -ManagedIdentity doesn't seem to support the Workload Identity federation. Would be great if this changed, so we don't have to retrieve the token separately
How do I know which service principal is really used?
You may use the following script to retrieve the object ID of the service principal:
$x = (Get-AzContext).Account.Id
$y = Get-AzADServicePrincipal -ApplicationId $x
Write-Host "##[debug] $($y.Id)"
Execute it from the AzurePowerShell@5 task with azureSubscription set to the name of the service connection using the Workload Identity federation
UPDATE 18.09.2024: It seems like the DefaultAzureCredential will support the Azure Pipeline's workload identity federation soon-ish: Support for Azure DevOps Workload Identity but "Unfortunately, it didn't make the cut for the current quarter. They're reconsidering the work for next quarter". Can't wait =)
Posted on October 10, 2023
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.