[Bug] Proxy and broker configuration logs may expose sensitive values

[qianye1001]

Before Creating the Bug Report

• I found a bug, not just a question.
• I searched existing GitHub issues and discussions and did not find a duplicate.
• I confirmed that the bug belongs to this repository.

Runtime platform environment

Any environment that starts Broker or Proxy, or updates Broker configuration at runtime, with sensitive configuration values.

RocketMQ version

• Branch: develop
• Commit: 293f588571

JDK Version

Reproduced and verified with Amazon Corretto JDK 11.0.23.

Describe the Bug

Broker and Proxy print complete configuration snapshots to normal logs during startup. Broker runtime configuration updates also print the incoming properties and old/new replacement values. These log projections currently have no explicit sensitivity marker or masking policy, so values such as TLS key passwords, authentication bootstrap data, inner-client credentials, SOCKS proxy credentials, and metrics exporter headers may be exposed in log files.

This iteration covers the normal full-configuration startup logs of Broker and Proxy and the Broker dynamic configuration update log. Existing exception/error logs, Controller, BrokerContainer, and Namesrv are out of scope. The open-source Proxy currently has no runtime dynamic configuration reload path.

Steps to Reproduce

1. Configure Proxy with a non-empty tlsKeyPassword or metricsGrpcExporterHeader, or configure Broker with a non-empty metricsGrpcExporterHeader.
2. Start the corresponding component and inspect its configuration startup log.
3. Alternatively, update an annotated Broker configuration property at runtime.
4. Observe that the configured value is written without masking.

What Did You Expect to See?

Sensitive configuration fields should be explicitly marked and masked only in log projections. Broker dynamic logs should contain only properties whose values actually changed. The masked text should retain a short prefix and suffix for troubleshooting, while the original configuration object, parsing, serialization, update, persistence, and runtime behavior remain unchanged.

What Did You See Instead?

The full sensitive value is present in the log.

Additional Context

The proposed fix introduces a runtime field annotation and a shared log-only masking utility. Only explicitly annotated fields are masked; there is no key-name fallback. Unannotated fields remain unchanged even when their names contain words such as password, secret, AK, or SK.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed | Severity: High

The reported issue has been verified against the current codebase (develop @ 293f588571).

Root Cause: No centralized sensitivity-aware logging mechanism exists. Configuration objects are serialized through two generic paths that log values without masking:

• MixAll.printObjectProperties (MixAll.java:335) — direct logger.info(name + "=" + value) with no redaction
• Configuration.merge/mergeIfExist (Configuration.java:325,339) — logs raw old/new values
• Proxy startup (ProxyStartup.java:127) — serializes full ProxyConfig via JSON.toJSONString with no field filtering
• Metrics exporter header validation (ProxyMetricsManager.java:193, BrokerMetricsManager.java:405, ControllerMetricsManager.java:343) — logs invalid headers verbatim

Impact: Sensitive fields (tlsKeyPassword, metricsGrpcExporterHeader, innerClientAuthenticationCredentials, proxy credentials) are written to log files in plaintext. Log files typically have weaker access controls than config files and are ingested by aggregation systems, broadening the exposure surface.

Affected Components: Proxy, Broker, Controller, BrokerContainer — all configuration logging paths.

The proposed @SensitiveConfig marker approach is a sound direction. An automated fix proposal can be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Hi @qianye1001, thanks for reporting this!

I've analyzed this issue against the codebase and can confirm this appears to be a real bug.

Root Cause: ** Configuration logging code at multiple sites prints field values verbatim with no masking or sensitivity filtering. Specifically: (1) MixAll.printObjectProperties() (MixAll.java:309-340) uses reflection to log every non-static field as name=value with no masking; (2) ConfigurationManager.formatProxyConfig() (ConfigurationManager.java:60-63) serializes the entire ProxyConfig to JSON with no masking; (3) Configuration.merge() and mergeIfExist() (Configuration.java:325,339) log "Replace, key: {}, value: {} -> {}" with old/new values and no masking; (4) AdminBrokerProcessor.java:1141 logs the full incoming Properties object on runtime config updates with no masking. No masking/redaction logic exists anywhere in the codebase.
Affected Files: ** common/src/main/java/org/apache/rocketmq/common/MixAll.java, remoting/src/main/java/org/apache/rocketmq/remoting/Configuration.java, broker/src/main/java/org/apache/rocketmq/broker/processor/AdminBrokerProcessor.java, broker/src/main/java/org/apache/rocketmq/broker/BrokerStartup.java, proxy/src/main/java/org/apache/rocketmq/proxy/ProxyStartup.java, proxy/src/main/java/org/apache/rocketmq/proxy/config/ConfigurationManager.java, proxy/src/main/java/org/apache/rocketmq/proxy/config/ProxyConfig.java, common/src/main/java/org/apache/rocketmq/common/BrokerConfig.java, auth/src/main/java/org/apache/rocketmq/auth/config/AuthConfig.java

Analysis: ** The issue is valid. Sensitive configuration fields such as ProxyConfig.tlsKeyPassword (line 84), ProxyConfig.metricsGrpcExporterHeader (line 246), BrokerConfig.metricsGrpcExporterHeader (line 407), and AuthConfig.innerClientAuthenticationCredentials (line 39) are printed in full to normal log files during Broker/Proxy startup and Broker runtime configuration updates. The existing configBlackList mechanism only prevents updating certain configs via the admin API — it does not prevent logging them. There is no annotation, marker, or masking utility to protect sensitive values in log projections.

I'll prepare a fix spec and work on a PR. The community is welcome to provide feedback on the approach before implementation.

---

🤖 Automated issue analysis by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

Valid security concern. Configuration logging that outputs sensitive values (passwords, tokens, secret keys) to stdout/log files is a real risk — especially in containerized environments where logs are often collected centrally.

Root Cause: Proxy and Broker startup/shutdown paths log full configuration objects without masking sensitive fields.
Impact: Any operator or log-aggregation system with access to logs can see credentials in plaintext.
Severity: Medium-High (security)

Suggested approach:

• Maintain a set of known sensitive field names (e.g., password, secretKey, accessKey, token).
• Apply masking (****) when serializing config objects for logging.
• Consider a centralized ConfigPrinter utility that respects a @Sensitive annotation or field-name allowlist.

---

Automated evaluation by github-manager