anchor.diff:  }
   ----
   
  -Placeholder `${file:/secrets/mysql.properties:user}` says that `org.apache.kafka.common.config.provider.FileConfigProvider` should be used and this provider will read property file `/secrets/mysql.properties` and extracts property `user` from it to use it.
  +Here, the Placeholder `${file:/secrets/mysql.properties:user}` says that the file config provider should be used, reading the property file `/secrets/mysql.properties` and extracting the `user` property from it.
   
  -The file config provider is probably the simplest possible use case and it can be expected that other providers will appear that will integrate with secret repositories or identity management systems.
  -It should be noted though that file config provider is satisfactory in OpenShift/Kubernetes deployments as `secrets` objects could be injected into cluster pods as files and thus consumed by it.
  +The file config provider is probably the simplest possible implementation, and it can be expected that other providers will appear that will integrate with secret repositories or identity management systems.
  +It should be noted though that the file config provider is satisfactory in Kubernetes/OpenShift deployments, as `secrets` objects could be injected into cluster pods as files and thus consumed by it.
   
  -You can try our https://github.com/debezium/debezium-examples/tree/master/tutorial#using-externalized-secrets[tutorial] demonstrating a deployment of externalized secrets. Please note the two environment variables in Docker Compose `connect` service
  +We've created a version of the Debezium https://github.com/debezium/debezium-examples/tree/master/tutorial[tutorial example], which demonstrates a deployment of externalized secrets. Please note the two environment variables in the Docker Compose `connect` service:
   
  -```
  -     - CONNECT_CONFIG_PROVIDERS=file
  -     - CONNECT_CONFIG_PROVIDERS_FILE_CLASS=org.apache.kafka.common.config.provider.FileConfigProvider
  +```[source,yaml]
  +...
  +- CONNECT_CONFIG_PROVIDERS=file
  +- CONNECT_CONFIG_PROVIDERS_FILE_CLASS=org.apache.kafka.common.config.provider.FileConfigProvider
  +...
   ```
   
  -These envrionment variables are directly mapped into Kafka Connect worker properties as a functionality of the `debezium/connect` image.
  +These environment variables are directly mapped into Kafka Connect worker properties as a functionality of the `debezium/connect` image.
   
  -When you issue the REST call to get connector configuration you will see that the sensitive information is externalized and masked from unauthorized persons
  +When you issue the REST call to get the connector configuration, you will see that the sensitive information is externalized and masked from unauthorized users:
   
   ```
   curl -s http://localhost:8083/connectors/inventory-connector | jq .
  
positive.code: }
  ----
  
  The `username` and `password` are passed to the cluster as plain strings.
  Worse yet anybody who has access to Kafka Connect REST API can issue a `GET` request to obtain a configuration of the connector including the database credentials
  
  ```
  curl -s http://localhost:8083/connectors/inventory-connector | jq .
  
negative.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 other users of the Connect API.
  
  Let's remind how a connector registration request looks like for the MySQL Debezium connector:
  
  [source,json]
  ----
  