[security] Redact sensitive config values in startup logs

[litiliu]

Summary

• Redact sensitive configuration values when GlobalConfiguration logs startup properties.
• Match sensitive keys case-insensitively using Flink-style substring matching.
• Cover Fluss access-key variants such as fs.s3a.access.key, s3.access-key, and fs.oss.accessKeyId.

Fixes #3485

Test Plan

• mvn -pl fluss-common -Dtest=ConfigurationTest,GlobalConfigurationTest test

[litiliu]

@Prajwal-banakar PTAL

[Prajwal-banakar]

HI @litiliu Thanks for the fix, this looks good to me and i've one small question, the implementation uses substring matching (contains) for all sensitive key parts. Is this intentionally aligned with Flink's behavior? I'm asking because patterns such as token and secret may also match non-sensitive configuration keys.

[litiliu]

HI @litiliu Thanks for the fix, this looks good to me and i've one small question, the implementation uses substring matching (contains) for all sensitive key parts. Is this intentionally aligned with Flink's behavior? I'm asking because patterns such as token and secret may also match non-sensitive configuration keys.

@Prajwal-banakar Yes, this is intentional and aligned with Flink's existing behavior. The implementation follows the same semantics as GlobalConfiguration.isSensitive(...), which lowercases the key and checks whether it contains any of the configured sensitive key parts.

This can lead to conservative masking for keys containing terms like token or secret, even if they are not actually sensitive. I think that is acceptable here because it is safer to over-mask than to accidentally expose credentials, and it keeps the behavior consistent with the rest of Flink's configuration/logging handling. If we want stricter matching in the future, it should probably be changed centrally in Flink's sensitive-key detection logic rather than only at this call site.

[litiliu]

@luoyuxia please help review

[litiliu]

@fresh-borzoni PTAL

[fresh-borzoni]

@litiliu Thank you for the PR, left some comments, PTAL

[fresh-borzoni]

Also #3526 adds a second S3-cred list that already diverges, is it worth unifying?

[litiliu]

Good point. I agree it is worth unifying the S3 credential detection, but I would prefer to handle that in #3526 or a focused follow-up.

The matching in this PR is intentionally generic and conservative for log redaction, following Flink-style sensitive-key substring matching. The #3526 logic is S3-specific and should probably use a more precise matcher for supported S3 config prefixes/suffixes, such as s3., s3a., fs.s3a. plus credential-bearing suffixes.

I will keep this PR scoped to the generic redaction path and avoid folding a filesystem config refactor into it. We can extract a shared S3 credential matcher separately so #3526 and the S3 filesystem code do not drift.
What do you think？

[litiliu]

@fresh-borzoni Thanks for the careful review. I pushed updates for the actionable comments:

• Added private.key / private-key to the sensitive-key matching and covered the GCS private key cases in tests.
• Reused ConfigurationUtils.hideSensitiveValue(s) for dynamic reconfiguration logs, so datalake.* credential changes are redacted as well.
• Added an exact non-sensitive allowlist for the token-renewal configs using existing ConfigOptions, normalized case-insensitively, with lowercase/uppercase test coverage.

For the S3 credential matcher unification with #3526, I’d prefer to keep that as a focused follow-up since that path is S3-specific while this PR keeps the generic log-redaction behavior.

[fresh-borzoni]

@litiliu Thank you for the changes, LGTM overall, one comment:
ZooKeeperClient.upsertEntityConfigs seems to also log secrets by the glance, shall we fix it as well, WDYT?