anchor.diff:    "type": "source"
   }
   ----
  +
  +Please refer to the https://github.com/debezium/debezium-examples/tree/master/tutorial#using-externalized-secrets[README] of the tutorial example for complete instructions.
  
positive.code: :awestruct-tags: [ secrets, mysql, example ]
  :awestruct-layout: blog-post
  
  When a Debezium connector is deployed to a Kafka Connect instance it is sometimes necessary to keep database credentials hidden from cluster API users.
  
  Let's remind how connector registration request looks like for MySQL Debezium connector
  
  [source,json]
  ----
  
negative.code: }
  ----
  
  If one Kafka Connect cluster is shared by multiple connectors/teams, then this behaviour can be undesiable for security reasons.
  
  To solve the problem https://cwiki.apache.org/confluence/display/KAFKA/KIP-297%3A+Externalizing+Secrets+for+Connect+Configurations[KIP-297] ("Externalizing Secrets for Connect Configurations") was implemented in Kafka 2.0.
  
  The externalization expects there is at least one implementation class of the `org.apache.kafka.common.config.provider.ConfigProvider` interface.
  Kafka Connect provides the reference implementation `org.apache.kafka.common.config.provider.FileConfigProvider` that reads secrets from a file.
  Available config providers are configured at Kafka Connect worker level (e.g. in `connect-distributed.properties`) and are referred to from the connector configuration.
  
  An example of worker configuration would be this:
  
  ```
  config.providers=file
  config.providers.file.class=org.apache.kafka.common.config.provider.FileConfigProvider
  ```
  
  and the connector registration request will refer to it like so:
  
  [source,json]
  ----
  {
  