adds warning for --debug #127879
adds warning for --debug #127879
Conversation
Even secured decorator is used, with --debug during deployment secured data is logged in clear texts to output.
|
@Ericsson89-ger : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit f93dfe1: ✅ Validation status: passed
For more details, please refer to the build report. |
There was a problem hiding this comment.
Pull Request Overview
This PR adds a warning about the --debug parameter's impact on secure data logging in Azure Resource Manager Bicep deployments. The change clarifies that even when using the @secure() decorator, sensitive data can be exposed in plain text logs when the --debug flag is used during deployment.
Key Changes:
- Updated security documentation to warn users that
--debugbypasses secure parameter protections
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| Secure strings use the same format as string, and secure objects use the same format as object. With Bicep, you add the `@secure()` [decorator](./parameters.md#use-decorators) to a string or object. | ||
|
|
||
| When you set a parameter (or an output) to a secure string or secure object, the value of the parameter (or the output) isn't saved to the deployment history or logged. If you set that secure value to a property that isn't expecting a secure value, the value isn't protected. For example, if you set a secure string to a tag, that value is stored as plain text. Use secure strings for passwords and secrets. | ||
| When you set a parameter (or an output) to a secure string or secure object, the value of the parameter (or the output) isn't saved to the deployment history or logged (except if --debug parameter is used). If you set that secure value to a property that isn't expecting a secure value, the value isn't protected. For example, if you set a secure string to a tag, that value is stored as plain text. Use secure strings for passwords and secrets. |
There was a problem hiding this comment.
[nitpick] The warning about --debug should be more prominent and specific. Consider rephrasing to: 'the value of the parameter (or the output) isn't saved to the deployment history or logged. However, when using the --debug flag during deployment, secure values are logged in clear text.' This makes the security implication clearer and separates it from the main statement for better readability.
| When you set a parameter (or an output) to a secure string or secure object, the value of the parameter (or the output) isn't saved to the deployment history or logged (except if --debug parameter is used). If you set that secure value to a property that isn't expecting a secure value, the value isn't protected. For example, if you set a secure string to a tag, that value is stored as plain text. Use secure strings for passwords and secrets. | |
| When you set a parameter (or an output) to a secure string or secure object, the value of the parameter (or the output) isn't saved to the deployment history or logged. However, when using the `--debug` flag during deployment, secure values are logged in clear text. If you set that secure value to a property that isn't expecting a secure value, the value isn't protected. For example, if you set a secure string to a tag, that value is stored as plain text. Use secure strings for passwords and secrets. |
|
Could you review the proposed changes? Due to the upcoming conference, all merging and publishing is on hold until the morning of 18 November 2025. Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
bot
added
the
aq-pr-triaged
3 participants
Even secured decorator is used, with --debug during deployment secured data is logged in clear texts to output.