Clarification on use of user-assigned managed identity and github-hosted runners
The content of this action's README is conflicting with official guidance on MS Learn regarding the use of user-assigned managed identities (UAMI). The documentation listed above gives example of workflow to use with github-hosted runners and UAMI.
The README in the repo, however, states:
"Login With User-assigned Managed Identity" is only supported on GitHub self-hosted runners and the self-hosted runners need to be hosted by Azure virtual machines.
and gives the example
name: Run Azure Login with User-assigned Managed Identity
on: [push]
jobs:
build-and-deploy:
runs-on: self-hosted
steps:
- name: Azure login
uses: azure/login@v2
with:
auth-type: IDENTITY
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
enable-AzPSSession: true
where we can see runs-on: self-hosted and auth-type: IDENTITY.
From my own testing and long-time usage I can still use UAMI and github-hosted runners with this action, when not setting auth-type to IDENTITY:
- Workflow run: https://github.com/matsest/az-oidc-managed-identity-demo/actions/runs/11086989035/job/30805186207
- Workflow file: https://github.com/matsest/az-oidc-managed-identity-demo/actions/runs/11086989035/workflow
When using the same UAMI and setting auth-type: IDENTITY I get errors (see run, workflow file): Error: Failed to connect to MSI, check your managed service identity id.
This is also tested by explicitly setting auth-type: SERVICE_PRINCIPAL (see run, workflow file) which again works fine.
Based on my testing and experience with managed identities I would assume that the restriction on using auth-type: IDENTITY and self-hosted runners only really applies to system-assigned managed identities?
Related: https://github.com/Azure/login/issues/445, https://github.com/Azure/login/issues/422
Hi @matsest , I think you are confusing the two methods:
If you want to use user-assigned managed identity on github-hosted runners, you can only use OIDC or SP+Secret.
The statement in login-with-user-assigned-managed-identity is correct. You can simply click the guides links to see how it works. (Just check how to configure it on Azure and GitHub.) I think your questions will be answered.
FYI, we also maintain the official guidance on MS Learn. This page official guidance on MS Learn corresponds to login-with-openid-connect-oidc. And the page Use the Azure Login action with a managed identity corresponds to login-with-system-assigned-managed-identity and login-with-user-assigned-managed-identity.
Thanks for reply @YanaXu!
I see that the method described under "Login With OpenID Connect (OIDC)" describes that it is possible to use user-assigned managed identity, which is what I am also stating in this question and what I have tested to work successfully. I guess this is more about how the README content is structured and how it matches to the documentation provided on MS Learn.
Some comments:
If you want to use user-assigned managed identity on github-hosted runners, you can only use OIDC or SP+Secret.
- It is inherently not possible to use SP+Secret with User Assigned Managed Identity. UAMI can't have secrets.
I think you are confusing the two methods:
login-with-openid-connect-oidc login-with-user-assigned-managed-identity
- If it is meant to be a clear distinction between these methods in this action the latter should be renamed to e.g. "Login With User-Assigned Managed Identity on Azure VM". In the MS Learn docs this is explicitly stated in the sidebar as "Sign in with a managed identity configured on an Azure VM" - which makes sense and clearly separates it from the "Sign in With OpenID Connect" method. The "on an Azure VM" is the important distinction here.
For users who want to use 1) User-Assigned Managed Identity and 2) GitHub-hosted Runners it should be clear from the README what example in the README is relevant for them. To me the current "Login With User-Assigned Managed Identity" seems at first glance to be the relevant section, but is not the correct one (Login With OpenID Connect (OIDC) is). If the part about "Azure VM" had been more clearly stated it would be a more clear distinction.
Thanks, @matsest, I was confused about the wording of the headings as well. I also agree that adding "on an Azure VM" or "self-hosted Azure VM" would be helpful :)
So what is the solution for this issue? I am facing similar one and trying to wrap my mind around the logic that needs to go in the workflow yaml's.
The README is not too clear about this but to summarize this before closing...
Guides in README for:
- Login With OpenID Connect (OIDC) [Recommended] => describes generic scenario for both service principal and user-assigned managed identity
- Login With a Service Principal Secret => describes generic scenario for service principal with secret
Guides for:
- Login With System-assigned Managed Identity => describes specific scenario for using system-assigned managed identity on an Azure VM
- Login With User-assigned Managed Identity => describes specific scenario for using user-assigned managed identity on Azure VM