Feature Request: Ability to Pass Authentication Parameters Individually

It would be great if this action allowed passing in the Subscription ID, Tenant ID, Client ID, and Client Secret as individual parameters instead of bundled in a single JSON object (creds today). This would allow for easier use in pipelines that use Terraform (as it requires them split out). It would also make secret rotation easier as you don’t have to rebuilt the JSON object.

Potential syntax (as an alternative to the existing syntax):

- uses: azure/login@v1.1
      with:
        client_id: ${{ secrets.CLIENT_ID }}
        client_secret: ${{ secrets.CLIENT_SECRET }}
        subscription_id: ${{ secrets.SUBSCRIPTION_ID }}
        tenant_id: ${{ secrets.TENANTID }}

If you are open to PRs, I’d love to try this!

[ericsampson]

Here’s a proposal that might address all those questions, and is still simple for the new user; these 4 individual inputs would be for more advanced users.

• existing creds input works as it does now (except that it’s optional)
• add the following 4 new inputs, with the creds_ prefix to help indicate that they are related to the creds JSON blob:

- uses: azure/login@v1.1
      with:
        creds_client_id: ${{ secrets.CLIENT_ID }}
        creds_client_secret: ${{ secrets.CLIENT_SECRET }}
        creds_subscription_id: ${{ secrets.SUBSCRIPTION_ID }}
        creds_tenant_id: ${{ secrets.TENANTID }}

• Key point: any creds_ input overrides the corresponding value in the creds JSON (if passed in by the user). This is similar to how ASP.NET Core configuration providers allow settings to be overlayed. This is actually kind of nice for some use cases, like below.

In other words:

- uses: azure/login@v1.1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
        creds_client_secret: ${{ secrets.CLIENT_SECRET }} # overrides the secret contained in the creds JSON blob.

and so it just falls out that the basic simple use case still works unchanged:

- uses: azure/login@v1.1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

[jmservera]

I would also prefer to use individual secrets due to this potential issue as noted in the GitHub Documentation:

To help ensure that GitHub redacts your secret in logs, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs.

Any change in the tooling could potentially leak these secrets. In fact, if you try to “echo” the secret, it is not redacted by the platform. This should be documented as a risk when using the full json as a secret.