Deploy action ignoring azure login action with service principal on self hoster runners on Azure VM/VMSS instances with UAMI

[basabaris]

We are running our workflows on our self hosted github runners which are hosted on Azure VMSS instances. The VMSS has user assigned managed identity. (We are using UAMI to access storage account for Custom Script Extension).

We use azure/login@2 action to login with service principal secrets:

    - name: 'Azure Login'
      uses: azure/login@v2
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS}}

    - name: Deploy ARM Template
      uses: azure/bicep-deploy@v2
      with:
        scope: ${{ inputs.deploymentScope }}
        type: deployment
        operation: create
        subscription-id: ${{ inputs.subscriptionId }}
        template-file: ${{ github.workspace }}/BicepDeploymentFiles/${{ inputs.templatePath }}
        parameters: ${{ inputs.deploymentParameters }}
        name: ${{ inputs.deploymentName }}
        location: ${{ inputs.deploymentLocation }}

However, azure/bicep-deploy@v2 task is still trying to access with user assigned managed identity of VMSS instead of service principal.

The only workaround currently is parsing the AZURE_CREDENTIALS json and setting environment credentials:

    - name: Deploy ARM Template
      uses: azure/bicep-deploy@v2
      with:
        scope: ${{ inputs.deploymentScope }}
        type: deployment
        operation: create
        subscription-id: ${{ inputs.subscriptionId }}
        template-file: ${{ github.workspace }}/BicepDeploymentFiles/${{ inputs.templatePath }}
        parameters: ${{ inputs.deploymentParameters }}
        name: ${{ inputs.deploymentName }}
        location: ${{ inputs.deploymentLocation }}
      env:
        AZURE_CLIENT_ID:  ${{ steps.parse-credentials.outputs.client_id }}
        AZURE_TENANT_ID:  ${{ steps.parse-credentials.outputs.tenant_id }}
        AZURE_CLIENT_SECRET:  ${{ steps.parse-credentials.outputs.client_secret }}

Any idea which might solve this issue? The current workaround is quite dirty solution and want to get rid of it.

[SydneyhSmith]

Thanks for the issue, this one is tricky because changing the behavior of log-in could have unintended effects. Agree though that this is an unexpected experience. Would having a setting for the type of authentication you want to use meet your needs/expectations?

[SydneyhSmith]

Another option we are considering is to have the type of authentication specified in Bicep config, would that work for your use case?

[basabaris]

Hi @SydneyhSmith, thank you for your response. I think the issue is that the ChainedTokenCredential does not have any option to use Service Principal credentials. Current implementation checks whether EnvironmentCredentials are set. Either azure/login action should set required environment variables after succesfull login with service principal, or an input parameter in the bicep-deploy action needs to be introduced to use service principal credentials instead of ChainedTokenCredential.