Configurations that may contain sensitive information (password, token) should be defined as PASSWORD type, there are two reasons :
Raw value of these configurations must be visible to users on UI/ API responses and should be masked. Values of PASSWORD type configurations are masked in responses.
Connector configurations (and values) are logged at INFO level at various places (raw values for non-secret configurations) in Kafka Connect while it creates tasks/ connector.
This change is backward-compatible, since configuration values are never fetched fromSnowflakeSinkConnectorConfig object in connector (yet). Raw values passed to start() (parsedConfig) are directly used.
Pre-review checklist
[ ] This change should be part of a Behavior Change Release. See go/behavior-change.
[ ] This change has passed Merge gate tests
[ ] Snowpipe Changes
[ ] Snowpipe Streaming Changes
[ ] This change is TEST-ONLY
[ ] This change is README/Javadocs only
[ ] This change is protected by a config parameter eg snowflake.ingestion.method.
[ ] Yes - Added end to end and Unit Tests.
[ ] No - Suggest why it is not param protected
[ ] Is his change protected by parameter on the server side?
@sfc-gh-mbobowski Could you please take a look at this small change / PR?
We want to make sure that raw-values of sensitive configurations do not get logged anywhere.
Overview
Configurations that may contain sensitive information (password, token) should be defined as PASSWORD type, there are two reasons :
This change is backward-compatible, since configuration values are never fetched from
SnowflakeSinkConnectorConfig
object in connector (yet). Raw values passed to start() (parsedConfig
) are directly used.Pre-review checklist
snowflake.ingestion.method
.Yes
- Added end to end and Unit Tests.No
- Suggest why it is not param protected