Follow-up to #566
Split out from #566 as requested by MaddyMicrosoft. #620 documented that the masking is intentional; this issue is the feature request for an opt-out.
Use case
We hold the client ID in an environment variable and need to pass it between steps and jobs - it identifies which app registration a workflow ran as, and downstream steps consume it as ordinary configuration data, not as a credential.
Because azure/login calls core.setSecret() on the client ID, GitHub Actions registers it as a secret for the rest of the workflow. From that point on we cannot pass it through as a step or job output: the value is redacted on its way out, so consumers receive *** or nothing at all instead of the ID. The masking is also global and substring-based, so any other log line or output that happens to contain the ID is redacted too, which makes unrelated output hard to read.
To workaround this we have had to hand roll our own azure login using CLI commands, which is less than ideal. Alternative workarounds I've seen involve deliberately defeating the masking - re-deriving the ID downstream from a separate source, or splitting/obfuscating the string so Actions doesn't recognise it. Both are worse than the behaviour they work around.
Proposed solution
A new action input, masking left on by default so nothing changes for existing users:
- uses: azure/login@v2
with:
client-id: ${{ vars.AZURE_CLIENT_ID }}
tenant-id: ${{ vars.AZURE_TENANT_ID }}
subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
mask-client-id: false # default: trueOnly the client ID / service principal ID would be in scope.
This preserves the enterprise scenario described in #566, where the team configuring the identity differs from the teams consuming the token, while letting workflows that treat the client ID as public configuration opt out explicitly. Making it an opt-in flag rather than a default change also means the choice is visible in the workflow file, which addresses the surprise factor from #566 - today the masking is invisible until you notice *** somewhere you didn't expect.
Alternatives
An environment variable (e.g. AZURE_LOGIN_DISABLE_CLIENT_ID_MASK) would allow an org-wide default without editing every with: block; an input seems cleaner and more discoverable, but either works for us
Follow-up to #566
Split out from #566 as requested by MaddyMicrosoft. #620 documented that the masking is intentional; this issue is the feature request for an opt-out.
Use case
We hold the client ID in an environment variable and need to pass it between steps and jobs - it identifies which app registration a workflow ran as, and downstream steps consume it as ordinary configuration data, not as a credential.
Because azure/login calls core.setSecret() on the client ID, GitHub Actions registers it as a secret for the rest of the workflow. From that point on we cannot pass it through as a step or job output: the value is redacted on its way out, so consumers receive *** or nothing at all instead of the ID. The masking is also global and substring-based, so any other log line or output that happens to contain the ID is redacted too, which makes unrelated output hard to read.
To workaround this we have had to hand roll our own
azure loginusing CLI commands, which is less than ideal. Alternative workarounds I've seen involve deliberately defeating the masking - re-deriving the ID downstream from a separate source, or splitting/obfuscating the string so Actions doesn't recognise it. Both are worse than the behaviour they work around.Proposed solution
A new action input, masking left on by default so nothing changes for existing users:
Only the client ID / service principal ID would be in scope.
This preserves the enterprise scenario described in #566, where the team configuring the identity differs from the teams consuming the token, while letting workflows that treat the client ID as public configuration opt out explicitly. Making it an opt-in flag rather than a default change also means the choice is visible in the workflow file, which addresses the surprise factor from #566 - today the masking is invisible until you notice *** somewhere you didn't expect.
Alternatives
An environment variable (e.g. AZURE_LOGIN_DISABLE_CLIENT_ID_MASK) would allow an org-wide default without editing every with: block; an input seems cleaner and more discoverable, but either works for us