Configuring properties for non-Kerberos authentication mechanisms
If your co-located Kafka cluster uses an authentication mechanism different from Kerberos, and you defined the co-located cluster through a service dependency, you need to copy and edit the srm-control tool's default configuration file generated by Cloudera Manager so that it includes the SASL properties of the co-located cluster.
The co-located Kafka cluster's properties for SASL mechanisms other than Kerberos cannot be
added to the secure storage using Cloudera Manager. Instead, if your co-located Kafka
cluster uses an authentication mechanism different from Kerberos, and you defined the
co-located cluster through a service dependency, the SASL properties must be directly added
to the configuration file that the
srm-control tool uses.
This is done by creating a copy of the default configuration file that Cloudera Manager generates and editing the copy so that it contains the necessary SASL properties.
Ensure that you have reviewed the information available in Configuring srm-control and understand that the following step list is only one part of the full configuration workflow. Depending on your scenario, completing other configuration tasks might be required.
Ensure that setup and configuration of the SRM service is complete:
The Kafka clusters that SRM connects to are defined and are added to the SRM service’s configuration. This includes both external and co-located clusters.
Replications are configured.
- SSH into one of the SRM hosts in your cluster.
- Create a copy of the default configuration file.For example:
cp /etc/streams_replication_manager/conf/srm.properties /tmp
- Open the copy of the configuration file with an editor.
- Add the necessary SASL properties to the file.The exact properties and values you add to the file depends on the type of SASL authentication used by the co-located Kafka cluster. The following example is for a cluster that uses PLAIN authentication:
[***ALIAS***]with the co-located cluster’s alias. Additionally, Cloudera does not recommend storing the JAAS configuration directly in the file. Instead, store the JAAS configuration in an environment variable and specify the environment variable as the value of the
[***ALIAS***].sasl.jaas.config property. This practice is recommended for any other sensitive data that you add to the configuration.
In a case like this, the environment variable you use to store the sensitive data must be set in your CLI session before running the tool. For example:
export custom_jaas_config = “org.apache.kafka.common.security.plain.PlainLoginModule required username="[***USER NAME***]" password="[***PASSWORD***]";”
- Save the file.