An understanding of the following topics will help in successfully securing Control Center:
Simply having a secured Kafka broker does not guarantee that Control Center is
secured and working properly. Each component that communicates with a secured
Control Center instance requires a specific configuration to be set by its prefix.
Prefixes such as
confluent.monitoring.interceptor. could conceivably be configured in
different files of the Confluent Platform stack to secure Control Center end-to-end. Not all
configuration settings may be required; consult the configuration references for
each component you are configuring.
Control Center supports SSL one- and two-way authentication and can be enabled for different communications. Some possible configurations are:
- secured Client interceptors (Connect/Confluent/regular client) -> secured Control Center Broker
- secured Kafka Broker -> secured Control Center Broker
- secured Metrics Reporter + secured Kafka Broker -> secured Control Center Broker
If an Apache Kafka® broker has been set up to use SSL, the same configurations need to be set for the metrics reporter. In the aforementioned link, a broker was set with the following configuration:
... ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks ssl.keystore.password=test1234 ssl.key.password=test1234 ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks ssl.truststore.password=test1234 ...
To secure the metrics reporter on the broker, use the same values with the prefix
To secure the stream monitoring interceptor on the broker, use the same values with the prefix
confluent.metrics.reporter.security.protocol=SSL confluent.metrics.reporter.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks confluent.metrics.reporter.ssl.keystore.password=test1234 confluent.metrics.reporter.ssl.key.password=test1234 confluent.metrics.reporter.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks confluent.metrics.reporter.ssl.truststore.password=test1234
Any configuration for the interceptor is prefixed by
With any of the configuration changes, a restart of the service is required. When restarting brokers, make sure each broker is available before restarting another.
Control Center Kafka Streams¶
Control Center needs to know when security is enabled for any other component. Internally, Control Center uses Kafka Streams as a state store, so with a secured broker, Kafka Streams also need to be secured.
The following changes need to be made to the
control-center.properties file as appropriate for the
security.protocol=SSL ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks ssl.keystore.password=test1234 ssl.key.password=test1234 ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks ssl.truststore.password=test1234 confluent.controlcenter.streams.security.protocol=SSL confluent.controlcenter.streams.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks confluent.controlcenter.streams.ssl.keystore.password=test1234 confluent.controlcenter.streams.ssl.key.password=test1234 confluent.controlcenter.streams.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks confluent.controlcenter.streams.ssl.truststore.password=test1234
For a detailed explanation of configuring Apache Kafka® client interceptors, see Enabling Interceptors.
This section describes how to configure Connect worker interceptors with SSL and how to configure Control Center to communicate with Connect over HTTPS.
Configuring Connect Worker Interceptors with SSL¶
The modifications to distributed connect works very similarly to the
The connect documentation covers this thoroughly.
Complete Configuring Workers with Security and Configuring Connectors with Security. Control Center uses both of those.
In addition to the generic Connect and producer/consumer changes, the monitoring interceptors should take the same configuration in
#### Monitoring producer interceptor #### producer.confluent.monitoring.interceptor.security.protocol=SSL producer.confluent.monitoring.interceptor.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks producer.confluent.monitoring.interceptor.ssl.truststore.password=test1234 producer.confluent.monitoring.interceptor.ssl.keystore.location=/var/private/ssl/kafka.source.keystore.jks producer.confluent.monitoring.interceptor.ssl.keystore.password=connector1234 producer.confluent.monitoring.interceptor.ssl.key.password=connector1234 consumer.confluent.monitoring.interceptor.security.protocol=SSL consumer.confluent.monitoring.interceptor.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks consumer.confluent.monitoring.interceptor.ssl.truststore.password=test1234 consumer.confluent.monitoring.interceptor.ssl.keystore.location=/var/private/ssl/kafka.source.keystore.jks consumer.confluent.monitoring.interceptor.ssl.keystore.password=connector1234 consumer.confluent.monitoring.interceptor.ssl.key.password=connector1234
Configuring Control Center to communicate with Connect over HTTPS¶
Confluent Control Center communicates with Connect using the HTTP protocol, which can be secured with SSL (also known as HTTPS). Make sure that Control Center has a certificate in its truststore that is trusted by Connect to communicate over HTTPS. The following variables are required in Control Center for HTTPS communication with Connect:
# HTTP and HTTPS to Control Center UI CONTROL_CENTER_REST_LISTENERS: "<http://0.0.0.0:9021,https://0.0.0.0:9022"> CONTROL_CENTER_REST_SSL_TRUSTSTORE_LOCATION: /etc/kafka/secrets/kafka.control-center.truststore.jks CONTROL_CENTER_REST_SSL_TRUSTSTORE_PASSWORD: confluent CONTROL_CENTER_REST_SSL_KEYSTORE_LOCATION: /etc/kafka/secrets/kafka.control-center.keystore.jks CONTROL_CENTER_REST_SSL_KEYSTORE_PASSWORD: confluent CONTROL_CENTER_REST_SSL_KEY_PASSWORD: confluent
For additional information about accessing Connect over HTTPS, refer to Configuring the Connect REST API for HTTP or HTTPS.
Confluent Control Center communicates with ksqlDB using the HTTP protocol, which can be secured with SSL (also known as HTTPS). To configure Control Center to connect to ksqlDB over HTTPS, refer to Configure ksqlDB for https.
Ensure that Control Center has a certificate in its truststore that is trusted by ksqlDB to communicate over HTTPS.
When Confluent Control Center connects to Schema Registry and Schema Registry has SSL enabled:
- Schema Registry communicates with Kafka over the Kafka protocol, which is secured with SSL.
- Control Center communicates with Kafka over the Kafka protocol, which is secured with SSL.
- Control Center communicates with Schema Registry over the HTTP protocol (also known as HTTPS), which is secured with SSL .
Essentially, Control Center functions as an HTTPS client to Schema Registry. To secure Control Center with HTTPS, configure Schema Registry to allow HTTPS as described in Configuring the REST API for HTTP or HTTPS.
In addition, Control Center should include a trusted certificate to its truststore to connect to Schema Registry over HTTPS as described in Additional configurations for HTTPS.
Be sure to prefix the Control Center configuration attributes in
confluent.controlcenter. For example:
confluent.controlcenter.schema.registry.schema.registry.ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks confluent.controlcenter.schema.registry.schema.registry.ssl.truststore.password=<password> confluent.controlcenter.schema.registry.schema.registry.ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks confluent.controlcenter.schema.registry.schema.registry.ssl.keystore.password=<password> confluent.controlcenter.schema.registry.schema.registry.ssl.key.password=<password>
Since the Control Center is a client for many different components, its client prefix includes the component, in this case Schema Registry:
With the exception of
confluent.controlcenter.schema.registry.url, the use of additional Schema Registry configurations are formatted with the
confluent.controlcenter.schema.registry prefix plus the Schema Registry configuration suffix. For example, the SSL truststore location is set as follows:
The repetition of
schema.registry in these configurations is intentional.