Allow prevent_secrets parameter value to be visible in logs
Problem to solve
Currently, the prevent_secrets parameter value is automatically filtered out in GitLab logs because it contains the word "secret". This filtering is controlled by the parameter filtering configuration in config/application.rb.
The relevant code that causes this filtering is here: https://gitlab.com/gitlab-org/gitlab/-/blob/08d081ca8e665fe644a00d0054fdede69869290a/config/application.rb#L117
When the prevent_secrets parameter is logged (for example, in push rule updates), its value appears as "[FILTERED]" instead of showing the actual boolean value (true/false or 1/0).
Intended users
- GitLab administrators who need to audit push rule changes
- Users monitoring security-related configuration changes
User experience goal
When reviewing logs for push rule updates, administrators should be able to see the actual value of the prevent_secrets setting to understand what changes were made.
Proposal
Modify the parameter filtering configuration to exclude prevent_secrets from being filtered, since this parameter name refers to a feature setting rather than containing actual secret data.
What does success look like, and how can we measure that?
Success would be measured by:
- The
prevent_secretsparameter value appearing astrue/falseor1/0in logs instead of"[FILTERED]" - No regression in filtering of actual secret parameters
- Improved auditability of push rule configuration changes
What is the type of buyer?
This affects all GitLab instances where push rules are used and administrators need to audit configuration changes.
Links / references
- Current filtering implementation: https://gitlab.com/gitlab-org/gitlab/-/blob/08d081ca8e665fe644a00d0054fdede69869290a/config/application.rb#L117
- Related to push rules functionality and audit logging