anchor.diff:  ----
   $ export CONFLUENT_SECURITY_MASTER_KEY=Nf1IL2bmqRdEz2DO//gX2C+4PjF5j8hGXYSu9Na9bao=
   ----
  +
  +To protect this environment variable in a production host, you can set the master encryption key at the process level instead of the global machine level.
  +For example, you could set it in the systemd overrides for executed processes, restricting the environment directives file to root-only access.
   
   === Encrypt the value of a configuration parameter
   
  
positive.code: 
  === Update the value of the configuration parameter
  
  You may have a requirement to update sensitive data on a regular basis, to help them from getting stale.
  The configuration parameter `config.storage.topic` was originally set to `connect-configs`.
  If you need to change the value in the future, you can update it directly using the CLI.
  In the CLI below, pass in a file `/path/to/updated-config-and-value` that has written `config.storage.topic=newTopicName`, to avoid logging history showing the new value.
  
negative.code: 
  === Going to production
  
  So far we have covered how to create the master encryption key and encrypt secrets in the configuration files.
  We recommend that you operationalize this workflow by augmenting your orchestration tooling to distribute everything that you need for secret protection to work to the destination hosts.
  These hosts may include Kafka brokers, Connect workers, Confluent Schema Registry instances, KSQL servers, Confluent Control Center, etc., any service using password encryption.
  The CLI is flexible to accommodate whatever secret distribution model you prefer: you can either do the secret generation and configuration modification on each destination host directly, or do it all a single host and then distribute the encrypted secrets to the destination hosts.
  There are four required tasks:
  
  . Export the master encryption key into the environment on every host that will have a configuration file with secret protection.
  