Extend query config with query.masked config with Type.PASSWORD for secure query masking

[KGaneshDatta]

Problem

• Introduced an internal query.masked configuration of Type.Password to ensure secure logging by masking sensitive values and preventing accidental exposure.
• Enhanced the existing validation to enforce that the connector operates exclusively in either table.mode or query.mode.
• Fixed the breaking connector validations in query mode with the new tableFilteringOptions introduced in 10.8.5. Issue

Solution

Does this solution apply anywhere else?

• yes
• no

If yes, where?

Test Strategy

Testing done:

• Unit tests
• Integration tests
• System tests
• Manual tests

Release Plan

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}

[Animesh Kumar (akanimesh7)]

Few things KGaneshDatta

1. Since query was never exposed on cloud before this, we should perform some manual testing to understand/validate the behaviour. (How frequently will the query be executed, What if the query is taking too long to exceute ? do we have any observability into this ? Can multiple queries be provided (select * from table1;select* from table2;))
2. If user has specified both table include/exclude list and query, we don't know which way they wanna go. The validation exception message currently instructs them to remove table include/exclude configs. Which might be other way round also.

[Animesh Kumar (akanimesh7)]

Missing validation -- If mode is query and timestamp.initial is provided validation passes.

[KGaneshDatta]

Missing validation -- If mode is query and timestamp.initial is provided validation passes.

The query mode would be working in timestamp criteria also. More details here - https://docs.confluent.io/kafka-connectors/jdbc/current/source-connector/overview.html#specifying-a-where-clause-with-query-modes
This also has been tested on CCloud with timestamp mode. Hence, when query was working in timestamp mode, I feel it would be valid to configure timestamp.initial when it is used.

[Animesh Kumar (akanimesh7)]

trim.sensitive.log is a config which was already existing in the sink connectors.
Now we are using the same config in source connectors. Although we have defined it in the ConfigDef, but there is no way to set a value for this config. Please check this.

[sonarqube-confluent]

Quality Gate passed

Issues
28 New issues
0 Accepted issues

Measures
1 Security Hotspot
86.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[Animesh Kumar (akanimesh7)]

Thanks KGaneshDatta