[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