Monitoring: Document redacted secret headers in functional logs

[iniw]

For COR-1962, operator change: metalbear-co/operator#2553.

The operator now writes [REDACTED] in place of the values of headers and message properties whose names often hold secrets, in the Message Processing functional logs. This updates the monitoring page: the request_headers and message_properties fields, which name parts match and how, and a warning that other names and secrets inside values are still logged.

Customers need the full list for their security reviews, so the page shows all the parts. The operator code has a comment that tells maintainers to change both together.

Merge this only after the operator release that has the change. The page says 3.215.0, the next release after 3.214.0. Check that number before you merge.

[linear-code]

COR-1962

[qodo-code-review]

PR Summary by Qodo

Document secret-value redaction in Message Processing logs

📝 Documentation 🕐 10-20 Minutes

AI Description

• Document redaction of sensitive-name values in HTTP headers and message properties starting with
 Operator 3.215.0.
• List the name-matching rules and warn that other values, including nested secrets, remain logged.

Diagram

graph TD
  A["Header or property"] --> B["Normalize name"] --> C{"Sensitive part?"}
  C -->|Yes| D["Redact value"] --> F["Functional log"]
  C -->|No| E["Keep value"] --> F

Loading

High-Level Assessment

Documenting the behavior beside the existing Message Processing fields gives readers the rules and their limits in context. Confirm the published operator release is 3.215.0 and its matching list agrees before merging.

Files changed (1) +5 / -3

Documentation (1) +5 / -3

monitoring.mdExplain sensitive-name redaction in functional logs +5/-3

Explain sensitive-name redaction in functional logs

• Clarifies that request headers and message properties with matching names have their values replaced with [REDACTED] starting in Operator 3.215.0. Lists the normalization and matching rules and warns that nonmatching values and nested secrets can still appear in logs.

docs/managing-mirrord/monitoring.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

1. Documentation can precede the operator release 🔗 Cross-repo conflict ☼ Reliability

Description

The monitoring page announces header and property redaction starting with Operator 3.215.0, while
the pinned operator branch containing the implementation still declares version 3.214.0. Publishing
this documentation before the release/version bump reaches customers can describe behavior that
their installed Operator does not provide.

Code

docs/managing-mirrord/monitoring.md[178]

+Starting with mirrord Operator `3.215.0`, the Operator writes `[REDACTED]` in place of the value of a header or message property when its name often holds a secret. The Operator uses only the ASCII letters and digits of the name, in lowercase, and the name matches when they contain one of these parts: `accesskey`, `apikey`, `appcheck`, `auth`, `cookie`, `credential`, `csrf`, `encryptioncustomerkey`, `encryptionkey`, `functionskey`, `hmac`, `jwt`, `oidcdata`, `passphrase`, `passw`, `privatekey`, `pwd`, `secret`, `session`, `signature`, `subscriptionkey`, `token`, or `xsrf`. For example, the values of `Authorization`, `Cookie`, `X-Api-Key`, `api.key`, `Client-Secret` and `db_password` are redacted. The name stays in the record, so you can still see which headers or properties a message had.

Relevance

●●● Strong

Accepted history consistently corrects inaccurate minimum-version claims and requires documentation
to match released Operator behavior.

PR-#325
PR-#359
PR-#322

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR introduces the 3.215.0 availability claim. The related operator repository still declares
version 3.214.0 at the pinned commit, even though that commit contains the corresponding redaction
implementation and documentation-coordination comment, proving the release/version alignment is not
yet complete.

docs -> operator
docs/managing-mirrord/monitoring.md[178-178]
External repo: metalbear-co/operator, Cargo.toml [19]
External repo: metalbear-co/operator, crates/operator-context/src/event/functional_log.rs [165-202]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The documentation claims that redaction starts with Operator 3.215.0, but the related operator branch currently declares version 3.214.0. Merging or publishing the documentation before the operator release/version bump is available can cause users of the documented version to expect redaction that is not present.

## Fix Focus Areas
- docs/managing-mirrord/monitoring.md[178-178]
- /cross_repos/operator/Cargo.toml[19-19]
- /cross_repos/operator/crates/operator-context/src/event/functional_log.rs[165-202]

## Recommended Fix
Merge or publish this documentation only after the operator change is released under version 3.215.0, and verify the release/version bump before merging. Alternatively, keep the documentation version aligned with the actually released operator version.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

Context sources

✅ Tickets: 🎫 Sanitize request header keys commonly associated with secrets

✅ Cross-repo context — repo relationships

  Explored: repo: metalbear-co/operator (branch: vinicius/cor-1962-sanitize-request-header-keys-commonly-associated-with, sha: 4818d189) — View relationship

Review mode: 🚀 Fast: This is a localized, documentation-only change with no runtime behavior or contract implementation changes, though the security-related wording and version should receive a focused light review.

Tip of the day

💡 Did you know, you can keep summaries lean with Findings visible per group, which tucks the rest behind a View link

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Documentation can precede the operator release 🔗 Cross-repo conflict ☼ Reliability

The monitoring page announces header and property redaction starting with Operator 3.215.0, while
the pinned operator branch containing the implementation still declares version 3.214.0. Publishing
this documentation before the release/version bump reaches customers can describe behavior that
their installed Operator does not provide.

Agent Prompt

## Issue description
The documentation claims that redaction starts with Operator 3.215.0, but the related operator branch currently declares version 3.214.0. Merging or publishing the documentation before the operator release/version bump is available can cause users of the documented version to expect redaction that is not present.

## Fix Focus Areas
- docs/managing-mirrord/monitoring.md[178-178]
- /cross_repos/operator/Cargo.toml[19-19]
- /cross_repos/operator/crates/operator-context/src/event/functional_log.rs[165-202]

## Recommended Fix
Merge or publish this documentation only after the operator change is released under version 3.215.0, and verify the release/version bump before merging. Alternatively, keep the documentation version aligned with the actually released operator version.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

[greptile-apps]

[Low risk] Documents secret redaction in monitoring logs.

No actionable defect was established; merge only after the stated Operator release and version are confirmed.

Summary

The PR documents name-based redaction of secret-bearing HTTP headers and message properties in Message Processing logs.

• Adds the matching-name rules, examples, and a warning about values that remain visible.
• Greptile automatically discovered a related ticket that helped explain the purpose of this PR: sanitizing request-header keys commonly associated with secrets.

_{Reviews (1) · Last reviewed commit: "Monitoring: Document redacted secret hea..."}