Configuring Security for KSQL¶
KSQL supports many of the security features of both Apache Kafka and Schema Registry.
- KSQL supports Apache Kafka security features such as SSL for encryption, SASL for authentication, and authorization with ACLs.
- KSQL supports Schema Registry security features such SSL for encryption and mutual authentication for authorization.
To configure security for KSQL, add your configuration settings to the
file and then start the KSQL server with your configuration file specified.
$ <path-to-confluent>/bin/ksql-server-start <path-to-confluent>/etc/ksql/ksql-server.properties
These instructions assume you are installing Confluent Platform by using ZIP or TAR archives. For more information, see On-Premises Deployments.
Configuring KSQL for Confluent Cloud¶
You can use KSQL with a Kafka cluster in Confluent Cloud. For more information, see Connecting KSQL to Confluent Cloud.
Configuring KSQL for Secured Confluent Schema Registry¶
You can configure KSQL to connect to Schema Registry over HTTP by setting the
ksql.schema.registry.url to the HTTPS endpoint of Schema Registry.
Depending on your security setup, you might also need to supply additional SSL configuration.
For example, a trustStore is required if the Schema Registry SSL certificates are not trusted by
the JVM by default; a keyStore is required if Schema Registry requires mutual authentication.
You can configure SSL for communication with Schema Registry by using non-prefixed names,
ssl.truststore.location, or prefixed names, e.g.
Non-prefixed names are used for settings that are shared with other communication
channels, i.e. where the same settings are required to configure SSL communication
with both Kafka and Schema Registry. Prefixed names only affect communication with Schema Registry
and override any non-prefixed setting of the same name.
Use the following to configure KSQL to communicate with Schema Registry over HTTPS, where mutual authentication is not required and Schema Registry SSL certificates are trusted by the JVM:
Use the following to configure KSQL to communicate with Schema Registry over HTTPS, with mutual authentication, with an explicit trustStore, and where the SSL configuration is shared between Kafka and Schema Registry:
ksql.schema.registry.url=https://<host-name-of-schema-registry>:<ssl-port> ssl.truststore.location=/etc/kafka/secrets/ksql.truststore.jks ssl.truststore.password=confluent ssl.keystore.location=/etc/kafka/secrets/ksql.keystore.jks ssl.keystore.password=confluent ssl.key.password=confluent
Use the following to configure KSQL to communicate with Schema Registry over HTTP, without mutual authentication and with an explicit trustStore. These settings explicitly configure only KSQL to Schema Registry SSL communication.
ksql.schema.registry.url=https://<host-name-of-schema-registry>:<ssl-port> ksql.schema.registry.ssl.truststore.location=/etc/kafka/secrets/sr.truststore.jks ksql.schema.registry.ssl.truststore.password=confluent
The exact settings will vary depending on the encryption and authentication mechanisms Schema Registry is using, and how your SSL certificates are signed.
You can pass authentication settings to the Schema Registry client used by KSQL by adding the following to your KSQL server config.
For more information, see Schema Registry Security Overview.
Configuring KSQL for Secured Apache Kafka clusters¶
The following are common configuration examples.
Configuring Kafka Encrypted Communication¶
This configuration enables KSQL to connect to a Kafka cluster over SSL, with a user supplied trust store:
security.protocol=SSL ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks ssl.truststore.password=confluent
The exact settings will vary depending on the security settings of the Kafka brokers, and how your SSL certificates are signed. For full details, and instructions on how to create suitable trust stores, please refer to the Security Guide.
Configuring Kafka Authentication¶
This configuration enables KSQL to connect to a secure Kafka cluster using PLAIN SASL, where the SSL certificates have been signed by a CA trusted by the default JVM trust store.
security.protocol=SASL_SSL sasl.mechanism=PLAIN sasl.jaas.config=\ org.apache.kafka.common.security.plain.PlainLoginModule required \ username="<ksql-user>" \ password="<password>";
The exact settings will vary depending on what SASL mechanism your Kafka cluster is using and how your SSL certificates are signed. For more information, see the Security Guide.
Configuring Control Center Monitoring Interceptors¶
This configuration enables SASL and SSL for the monitoring intercepts that integrate KSQL with Control Center.
# Confluent Monitoring Interceptors for Control Center streams monitoring producer.interceptor.classes=io.confluent.monitoring.clients.interceptor.MonitoringProducerInterceptor consumer.interceptor.classes=io.confluent.monitoring.clients.interceptor.MonitoringConsumerInterceptor # Confluent Monitoring interceptors SASL / SSL config confluent.monitoring.interceptor.security.protocol=SASL_SSL confluent.monitoring.interceptor.ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks confluent.monitoring.interceptor.ssl.truststore.password=confluent confluent.monitoring.interceptor.ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks confluent.monitoring.interceptor.ssl.keystore.password=confluent confluent.monitoring.interceptor.ssl.key.password=confluent confluent.monitoring.interceptor.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="ksql-user" password="ksql-user-secret"; confluent.monitoring.interceptor.sasl.mechanism=PLAIN
- Learn More
- See the blog post Secure Stream Processing with Apache Kafka, Confluent Platform and KSQL and try out the Monitoring Kafka streaming ETL deployments tutorial.