Support Managed Identity

[YanaXu]

Description

This PR is going to support both system- and user- assigned managed identity login for self-hosted runners on Azure VM.

What's new

• The Action provides a parameter auth-type with value list [SERVICE_PRINCIPAL, IDENTITY] to identify the type of authentication.
  1. If auth-type: SERVICE_PRINCIPAL with clientId, tenantId and clientSecret detected in your input, we will attempt to login by using service principal with the secret.

  #login with secret
  - uses: azure/login@v1
        with:
          auth-type: SERVICE_PRINCIPAL
          creds: ${{ secrets.AZURE_CREDENTIALS }}

  2. If auth-type: SERVICE_PRINCIPAL with clientId and tenantId detected in your input, we will attempt to login by using OIDC.

  #login with OIDC
  - uses: azure/login@v1
      with:
          auth-type: SERVICE_PRINCIPAL
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  3. If auth-type: IDENTITY with clientId detected in your input, we will attempt to login by using user-assigned managed identity.

  #login with user-assigned managed identity
  - uses: azure/login@v1
     with:
         auth-type: IDENTITY
         client-id: ${{ secrets.AZURE_CLIENT_ID }}
         subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  4. If auth-type: IDENTITY without clientId detected in your input, we will attempt to login by using system-assigned managed identity.

  #login with system-assigned managed identity
  - uses: azure/login@v1
   with:
         auth-type: IDENTITY
         subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

The default value of auth-type to be SERVICE_PRINCIPAL to make it backward-compatible.

• Always specify the subscription-id for safety. Without doing so will make Azure CLI use the current active subscription, which can be risky if your default subscription has changed.

• The changes for README.md is in Update README.md for Managed identity #344.

[anton-delphai]

It seems like this change makes allow-no-subscriptions option useless as readParametersFromCreds() already throws an error without considering this option

[pawan-regoti]

a funny workaround is giving not null value to subscriptionId in creds and set allow-no-subscriptions to true. It will bypass the subscriptionId and not throws error saying subscriptionId is missing.

      - uses: azure/login@v1
        with:
          allow-no-subscriptions: true
          ...
          creds: '{"subscriptionId":"something"}'