Use a ConfigProvider. Kafka Connect lets you put a variable in a connector configuration instead of a secret, and the worker resolves it when the connector starts. The stored config and the REST API then show the variable, not the secret.
How it works
Confluent's Kafka Connect security guide, in its Externalize Secrets section, explains the mechanism. The ConfigProvider interface lets you use variables in worker configuration, resolved at startup, and in connector configuration, resolved when the connector is restarted. Connector configurations are persisted and shared over the Connect REST API with the variables in them. Only when the connector starts does it transiently resolve and replace variables in memory. The guide says secrets are never persisted in connector configurations, logs, or REST requests and responses.
The worker relies on named providers defined in its configuration. Each variable names the provider and carries the information needed to resolve it. Apache Kafka's worker config reference describes the config.providers property as a comma separated list of provider classes, loaded in the order given.
Why this matters
By default, anyone who can read connector configs over the REST API sees what is in them. If a database password sits there in clear text, so does it in every backup of the config topic and every screenshot of an API response. With a provider, the config holds a reference. See who can reach the Kafka Connect REST API on port 8083 for the access side.
What to check when you set it up
| Check | Why |
|---|---|
| Every worker can reach the secret source | The guide stresses workers must be able to resolve variables |
| Provider JARs sit in the right place | Custom providers go on the default classpath, not in a plugin subdirectory |
| Provider parameters are not themselves secrets in clear text | Parameters prefixed with config.providers dot name dot param go to the provider |
| Secret source has its own access control | The provider is only as safe as the store behind it |
On the second row, Confluent's guide says JAR files for a custom provider should not be placed under a subdirectory of the plugin path, since those locations are for connectors and their dependent JARs, not config providers. A mismatch there is a common reason a provider fails to load.
A migration path
- Pick the secret source your platform already uses.
- Define the provider in the worker configuration and restart workers.
- Replace each secret in connector configs with a variable, one connector at a time.
- Restart the connector and confirm it resolves.
- Read the REST API response for that connector and confirm only the variable shows.
- Rotate the old secret, since it sat in the config topic and any exports taken before.
Step six is the one teams skip. A secret that was ever stored in clear text must be treated as exposed to everyone who could read that store.
Limits
A provider keeps secrets out of stored configuration. It does not stop a connector from using the secret, and it does not restrict who can create connectors. A user who can create a connector can usually point it at a secret reference. That is an authorization question, covered by your cluster and REST access controls. See also Kafka ACLs: least privilege producer and consumer setup.
Safeguard's dependency scanning covers the connector JARs and libraries your workers load. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does the REST API show the resolved secret?
Per Confluent's guide, no. It shows the variable. Resolution happens in memory when the connector starts.
Do I still need to rotate old secrets after switching?
Yes. Anything that was stored in clear text before the switch should be treated as exposed to whoever could read that store.
Sources
- Kafka Connect security, Confluent documentation, fetched 19 October 2026.
- Kafka Connect configs, Apache Kafka documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
