Continuous Deployment RBAC Role Assignment Conflict¶

1. Summary¶

Symptom¶

When you reconnect (or first connect) Deployment Center container continuous deployment for an App Service Web App that uses Managed Identity to pull from Azure Container Registry, the Portal or az deployment group create returns:

RoleAssignmentExists: The role assignment already exists.
The ID of the existing role assignment is <32-char-hex>.

The error appears during the deployment step that grants the Web App's system-assigned managed identity the AcrPull role on the registry. The CD setup fails atomically: the GitHub Actions workflow may still be committed, but the Azure-side image-pull permission setup did not complete cleanly. The Web App itself continues to serve the previously deployed image, but the next pull attempt with a new image tag will fail with an authentication error if the AcrPull assignment is in an inconsistent state.

Why this scenario is confusing¶

The error message suggests something about the new assignment is wrong, but the actual cause is leftover state from the previous CD setup or from a separate IaC/manual grant. The Deployment Center "Disconnect" action removes the GitHub-side artifacts (workflow file, secrets) and clears site config bindings, but it does not reliably delete the AcrPull role assignment that was granted to the Web App's managed identity on the registry.

When you reconnect using the same Web App (same managed identity principal) and the same registry, ARM tries to create a role assignment with the same (scope, principalId, roleDefinitionId) triple but with a freshly generated assignment GUID. Azure RBAC rejects this because that triple is the unique key for a role assignment — you cannot have two assignments of the same role to the same principal on the same scope.

It is also confusing because the error refers to a role assignment ID, not to the principal or the role name, so you cannot tell from the message alone which permission is conflicting.

Troubleshooting decision flow¶

flowchart TD
    A[CD reconnect fails: RoleAssignmentExists] --> B{Error includes role assignment ID?}
    B -->|Yes| C[Convert hex to GUID and look up assignment]
    B -->|No| D[List role assignments on ACR scope]
    C --> E{Assignment principal is Web App MI?}
    D --> E
    E -->|Yes| F[Delete the existing AcrPull assignment]
    E -->|No| G[Investigate other RBAC source]
    F --> H{Web App still has system-assigned MI?}
    H -->|Yes| I[Reconnect CD - new assignment will be created]
    H -->|No| J[Re-enable system-assigned MI first]
    J --> I

2. Common Misreadings¶

• "Disconnect cleans up everything." Disconnect removes GitHub workflow and site config bindings only; the AcrPull role assignment on the registry usually remains.
• "Recreating the Web App fixed identity, so RBAC must be clean too." Deleting the Web App removes its managed identity principal, but the orphaned role assignment lingers (assignment principal is now a deleted object) until explicitly removed.
• "The error mentions a new role assignment, so the new one is malformed." The error is a uniqueness conflict — the old assignment exists and blocks the new identical one.
• "Just retry the wizard." Retrying produces the same conflict because the offending assignment is still there.
• "I should grant a different role." The container pull path requires AcrPull specifically (or a custom role with Microsoft.ContainerRegistry/registries/pull/read). Granting Reader or Contributor does not satisfy acrUseManagedIdentityCreds.

3. Competing Hypotheses¶

4. What to Check First¶

Error message details¶

The error returned by the deployment includes the conflicting role assignment ID without hyphens:

The ID of the existing role assignment is <role-assignment-id-no-hyphens>

Convert this 32-character hex string into a standard GUID by inserting hyphens at positions 8, 12, 16, and 20:

<role-assignment-id>

Platform Signals¶

SUBSCRIPTION_ID="<subscription-id>"
ROLE_ASSIGNMENT_ID="<role-assignment-id>"

az role assignment list \
    --subscription "$SUBSCRIPTION_ID" \
    --query "[?name=='$ROLE_ASSIGNMENT_ID']" \
    --output json

az role assignment show \
    --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID" \
    --output json

The output reveals the principal ID, role definition (AcrPull), and scope (the registry) of the conflicting assignment, which is enough to confirm hypothesis H1 or H2.

Cross-check related leftovers¶

RG="<your-resource-group>"
APP_NAME="<your-web-app-name>"
ACR_NAME="<your-acr-name>"

ACR_ID=$(az acr show --name "$ACR_NAME" --resource-group "$RG" --query id --output tsv)
APP_PRINCIPAL_ID=$(az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv)

az role assignment list --scope "$ACR_ID" --output table
az role assignment list --assignee "$APP_PRINCIPAL_ID" --all --output table
az webapp config show --name "$APP_NAME" --resource-group "$RG" \
    --query "{linuxFxVersion:linuxFxVersion, acrUseManagedIdentityCreds:acrUseManagedIdentityCreds, acrUserManagedIdentityID:acrUserManagedIdentityID}" \
    --output table

The acrUseManagedIdentityCreds: true setting confirms the Web App expects to authenticate to ACR via its own MI. If acrUserManagedIdentityID is set, a user-assigned MI is in use instead — adjust the principal lookup accordingly (az identity show).

The Activity log blade is the control-plane audit surface for RBAC investigation. Scope the Resource chip to the affected registry (or its resource group) rather than the app and set Timespan to the incident window; the Status, Time stamp, and Event initiated by columns give you the schema to correlate against the role-assignment ID returned by the CLI commands above. Use Download as CSV to export the filtered set into the incident ticket.

5. Evidence to Collect¶

Required Evidence¶

Useful Context¶

• Record when the previous CD was disconnected and what cleanup was performed (workflow deletion, site config update, role assignment delete attempts).
• Record whether the previous CD used a system-assigned managed identity, a user-assigned managed identity, admin credentials, or a service principal.
• Record whether the same Web App or a recreated one with the same name is involved.
• Record whether AcrPull was ever granted by IaC outside of Deployment Center (Bicep, Terraform, manual az role assignment create).

6. Validation and Disproof by Hypothesis¶

H1: Orphaned AcrPull assignment from previous Deployment Center CD setup¶

Signals that support:

• az role assignment show returns an assignment whose roleDefinitionName is AcrPull on the ACR scope.
• The principalId matches the current Web App's identity.principalId.
• The createdOn timestamp predates the current reconnect attempt and lines up with a previous Deployment Center configuration date.

Signals that weaken:

• The assignment was created today and references a principal you provisioned manually.
• The principal is unrelated to the Web App.

What to verify:

az role assignment show \
    --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID" \
    --query "{principal:principalId, role:roleDefinitionName, scope:scope, created:createdOn}" \
    --output json

az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv

If both principalId values match and roleDefinitionName is AcrPull scoped to the ACR, H1 is confirmed.

H2: AcrPull was previously granted by IaC and Deployment Center is now trying to re-grant it¶

Signals that support:

• Repository contains a Bicep/Terraform module that creates Microsoft.Authorization/roleAssignments for 7f951dda-4ed3-4680-a7ca-43fe172d538d (the AcrPull built-in role) on this ACR scope.
• The most recent successful deployment of that module precedes the failed Deployment Center attempt.
• az deployment group list --resource-group "$RG" --output table shows a prior Succeeded deployment that granted the same assignment.

Signals that weaken:

• No IaC artifact references this ACR scope.
• The IaC-managed assignment principal is different from the Web App MI.

What to verify: Search the repository for 7f951dda-4ed3-4680-a7ca-43fe172d538d or 'AcrPull' in Bicep/Terraform files. Confirm the deployment history with az deployment group list.

H3: Orphaned assignment from a deleted Web App reusing the same name¶

Signals that support:

• The principalId in the conflicting assignment cannot be resolved to an active object in Microsoft Entra ID.
• az ad sp show --id <principalId> returns "not found" (the previous Web App's MI was deleted with the previous Web App).
• The current Web App has a different principalId from the one in the assignment.

Signals that weaken:

• The principal resolves and equals the current Web App's principalId.

What to verify:

PRINCIPAL_ID=$(az role assignment show \
    --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID" \
    --query principalId --output tsv)
az ad sp show --id "$PRINCIPAL_ID" --output json 2>&1 || echo "principal does not exist"

H4: AcrPull was granted manually for testing¶

Signals that support:

• principalType in the conflicting assignment is User, or it is a service principal unrelated to App Service.

Signals that weaken:

• The principal matches the Web App MI exactly.

What to verify:

az role assignment show \
    --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID" \
    --query "principalType" \
    --output tsv

H5: Same registry shared by multiple Web Apps, all granted at once via a script¶

Signals that support:

• az role assignment list --scope "$ACR_ID" --query "[?roleDefinitionName=='AcrPull']" --output table returns multiple assignments, one per Web App MI sharing the registry.
• The current Web App's MI appears in that list with a createdOn value that predates the current reconnect attempt.

Signals that weaken:

• Only one AcrPull assignment exists on this ACR.

What to verify:

az role assignment list --scope "$ACR_ID" \
    --query "[?roleDefinitionName=='AcrPull'].{principalId:principalId, principalName:principalName, createdOn:createdOn}" \
    --output table

7. Likely Root Cause Patterns¶

8. Immediate Mitigations¶

1. Convert the role assignment ID from the error message into GUID format and capture the assignment details.

   SUBSCRIPTION_ID="<subscription-id>"
   ROLE_ASSIGNMENT_ID="<role-assignment-id>"
   az role assignment show \
       --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID" \
       --output json
   

   Command	Purpose
   SUBSCRIPTION_ID="<subscription-id>"	Sets a local shell variable used by the commands in this troubleshooting step.
   ROLE_ASSIGNMENT_ID="<role-assignment-id>"	Sets a local shell variable used by the commands in this troubleshooting step.
   az role assignment show --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID" --output json	Shows one specific role assignment so you can inspect its principal, role, and scope.
   --ids "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID"	Targets the exact ARM resource ID of the object to show or delete.
   --output json	Formats the command output as JSON for full-fidelity inspection.

2. Confirm the conflicting principal is the current Web App's managed identity.

   az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv
   

   Command	Purpose
   az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv	Shows the web app managed identity so you can verify which principal App Service is using.
   --name "$APP_NAME"	Specifies the target web app name for this command.
   --resource-group "$RG"	Selects the resource group that contains the target web app or related resource.
   --query principalId	Returns only the managed identity principalId value from the command output.
   --output tsv	Formats the command output as tab-separated text so it can be captured cleanly into a shell variable.

3. Delete the conflicting role assignment.

   ACR_ID=$(az acr show --name "$ACR_NAME" --resource-group "$RG" --query id --output tsv)
   az role assignment delete \
       --ids "${ACR_ID}/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID"
   

   Command	Purpose
   ACR_ID=$(az acr show --name "$ACR_NAME" --resource-group "$RG" --query id --output tsv)	Captures the command output into a local shell variable for reuse in later commands.
   --name "$ACR_NAME"	Specifies the Azure Container Registry name to inspect.
   --resource-group "$RG"	Selects the resource group that contains the target web app or related resource.
   --query id	Returns only the resource id field from the command output.
   --output tsv	Formats the command output as tab-separated text so it can be captured cleanly into a shell variable.
   az role assignment delete --ids "${ACR_ID}/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID"	Deletes the specified role assignment so the conflicting or stale RBAC entry is removed.
   --ids "${ACR_ID}/providers/Microsoft.Authorization/roleAssignments/$ROLE_ASSIGNMENT_ID"	Targets the exact ARM resource ID of the object to show or delete.

4. List remaining AcrPull assignments on the ACR scope and remove any other CD-related orphans for this Web App.

   az role assignment list --scope "$ACR_ID" \
       --query "[?roleDefinitionName=='AcrPull']" \
       --output table
   

   Command	Purpose
   az role assignment list --scope "$ACR_ID" --query "[?roleDefinitionName=='AcrPull']" --output table	Lists role assignments at the target scope so you can confirm whether AcrPull already exists there.
   --scope "$ACR_ID"	Limits the role-assignment lookup to this Azure resource scope.
   --query "[?roleDefinitionName=='AcrPull']"	Filters the returned list with this JMESPath expression before Azure CLI formats the output.
   --output table	Formats the command output as a readable table for quick triage.

5. Wait 15-30 seconds for RBAC propagation, then retry the Deployment Center connect (Portal) or re-run the failing ARM deployment.

   sleep 30
   az deployment group create \
       --resource-group "$RG" \
       --name "cd-reconnect-retry" \
       --template-file "<your-cd-template>.bicep" \
       --parameters webAppName="$APP_NAME" registryName="$ACR_NAME"
   

   Command	Purpose
   sleep 30	Pauses locally so Azure control-plane or RBAC changes have time to propagate before the next check.
   az deployment group create --resource-group "$RG" --name "cd-reconnect-retry" --template-file "<your-cd-template>.bicep" --parameters webAppName="$APP_NAME" registryName="$ACR_NAME"	Runs a resource-group deployment so you can retry the ARM/Bicep flow that previously failed.
   --resource-group "$RG"	Selects the resource group that contains the target web app or related resource.
   --name "cd-reconnect-retry"	Names this resource-group deployment operation.
   --template-file "<your-cd-template>.bicep"	Points Azure CLI to the local ARM/Bicep template file to deploy.
   --parameters webAppName="$APP_NAME" registryName="$ACR_NAME"	Passes the named parameter values into the template deployment.

6. Verify the new assignment exists and the Web App can pull the image.

   az role assignment list --assignee "$(az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv)" \
       --scope "$ACR_ID" \
       --output table
   
   az webapp log tail --name "$APP_NAME" --resource-group "$RG"
   

   Command	Purpose
   az role assignment list --assignee "$(az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv)" --scope "$ACR_ID" --output table	Lists role assignments for the specified principal so you can see what access that identity already has.
   --assignee "$(az webapp identity show --name "$APP_NAME" --resource-group "$RG" --query principalId --output tsv)"	Limits the role-assignment lookup to the specified principal or object ID.
   --scope "$ACR_ID"	Limits the role-assignment lookup to this Azure resource scope.
   --output table	Formats the command output as a readable table for quick triage.
   az webapp log tail --name "$APP_NAME" --resource-group "$RG"	Streams live app and platform log output from the target web app while you reproduce the issue.
   --name "$APP_NAME"	Specifies the target web app name for this command.
   --resource-group "$RG"	Selects the resource group that contains the target web app or related resource.

9. Prevention¶

• Treat Deployment Center disconnect as a multi-step cleanup: workflow file, GitHub secrets, site config (acrUseManagedIdentityCreds, linuxFxVersion), and the AcrPull role assignment on ACR.
• Pick one owner for the AcrPull grant: either Deployment Center or IaC (Bicep/Terraform). Do not let both manage the same assignment — they will fight on every reconnect.
• Manage CD identities and their role assignments in IaC so disconnects show up as code changes and orphaned assignments are obvious in drift detection.
• Use distinct Web App names per environment to avoid recycling the exact (scope, principal, role) triple.
• Document which identity model your team uses for container pulls (system-assigned MI, user-assigned MI, or admin credentials) so reconnects always pick the same option.
• Add a pre-flight check before reconnect that lists AcrPull assignments on the registry scope and warns about CD-related leftovers tied to the same Web App MI.
• Keep the role assignment ID returned by failures in your incident notes; it is the fastest path to root cause for future occurrences.

See Also¶

• CD Reconnect RBAC Conflict Lab
• Authentication Failures
• Deployment Failures

Sources¶

• https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?tabs=debian&pivots=container-linux
• https://learn.microsoft.com/en-us/azure/app-service/deploy-container-github-action
• https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-cli
• https://learn.microsoft.com/en-us/azure/role-based-access-control/troubleshooting
• https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/containers#acrpull