I have three Azure CD pipelines that follow similar steps. All three use a similarly named and used key that they fetch from a key vault. When I enable debug mode, the secret shows up in the logs of one deployment to a certain tenant.
Say I have these keys:
tenant1-pipelineA-secret << only this shows in debug logstenant2-pipelineA-secret << always redactedtenant1-pipelineB-secret << always redactedtenant2-pipelineB-secret << always redactedtenant1-pipelineB-secret << always redactedtenant2-pipelineB-secret << always redactedThe secret is only visible if system.Debug is set to true in the CD pipeline log that uses tenant1-pipelineA-secret. The strange thing is that this exact same secret is redacted with *** in a normal print statement of the same pipeline.
So the Azure pipeline logs look like this:
...
##[debug]tenant1-pipelineA-secret: "abcdefg123"
...
tenant1-pipelineA-secret: "***"
All the other CD pipelines, and the CD pipeline to tenant2, never show the secret in plain text, also not if system.Debug is enabled.
My suspicion is that the tenant1-pipelineA-secret key contains a special character that trips up the Azure key redaction step. Although I'm not sure why that only fails for a ##[debug] line, but not for a normal print. The keys are automatically generated and can contain the following characters: *!%#_/@-.
Any ideas why this one key is shown?
The issue was caused by me using a deprecated task: qetza.replacetokens.replacetokens-task.replacetokens. After upgrading from v3 to v6 the secret was hidden.
My original question was missing this detail.