log: redact sensitive data in logs

[BugenZhao]

We log user data in various scenarios. Some logs, such as (slow) query logs, can be enabled or disabled by users. However, there are other logs that will always be recorded without the users' explicit permission.

For example, we always log an error message on parsing or handling failure in pgwire, which contains the original SQL statement from users.

risingwave/src/frontend/src/session.rs

Lines 713 to 714 in d4a81e6

	let mut stmts = Parser::parse_sql(sql)
	.inspect_err(|e| tracing::error!("failed to parse sql:\n{}:\n{}", sql, e))?;

risingwave/src/frontend/src/session.rs

Line 748 in d4a81e6

.inspect_err(|e| tracing::error!("failed to handle sql:\n{}:\n{}", sql, e))?;

It's possible that there are sensitive literals in the SQL statement, or even some secrets for the connector definition.

For potential security policy considerations in the future, we may now carefully review all occurrences and replace them with redacted versions, including but not limited to SQL, and preferably in a type-safe manner. Redaction itself could be simple though: replacing all literals should be enough.

[xxchan]

found a ref: pingcap/tidb#18566 Seemingly this can only be enforced/fixed one by one.

[BugenZhao]

Some type-safe helpers:

• https://crates.io/crates/redact
• https://crates.io/crates/secrecy
• https://crates.io/crates/secstr

[kwannoel]

As a general example of when to reveal secrets: #13034 (comment).

[fuyufjh]

I guess we can only do this case by case manually. No way to automatically identify the occurrences. Feel free to open tasks for any cases disconvered.

[zwang28]

FYI, crdb's comprehensive and conservative approach to achieve log and error redaction, which provides APIs that "try to minimize the work needed by CockroachDB programmers, but sometimes extra care must be taken".
https://cockroachlabs.atlassian.net/wiki/spaces/CRDB/pages/1824817806/Log+and+error+redactability

"we consider anything unsafe until we have very good reasons not to; everything gets redacted except for those bits which we know are safe." I think this white list approach is too heavy for us at the moment.