Configuring Security for KSQL¶
KSQL supports many of the security features of both Apache Kafka and the 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 Install.
Table of Contents
- Configuring KSQL for Confluent Cloud
- Configuring KSQL for Secured Confluent Schema Registry
- Configuring KSQL for Secured Apache Kafka clusters
- Configuring Kafka Encrypted Communication
- Configuring Kafka Authentication
- Configuring Authorization of KSQL with Kafka ACLs
- Confluent Platform v5.0 (Apache Kafka v2.0) and above
- ACLs on Literal Resource Pattern
- ACLs on Prefixed Resource Pattern
- Confluent Platform versions below v5.0 (Apache Kafka < v2.0)
- Configuring Control Center Monitoring Interceptors
You can use KSQL with a Kafka cluster in Confluent Cloud. For more information, see Connecting KSQL to Confluent Cloud.
KSQL can be configured to connect to the Schema Registry over HTTP by setting the
ksql.schema.registry.url to the Schema Registry’s HTTPS endpoint.
Depending on your security setup, you might also need to supply additional SSL configuration.
For example, a trustStore is required if the Schema Registry’s SSL certificates are not trusted by
the JVM by default; a keyStore is required if the Schema Registry requires mutual authentication.
SSL configuration for communication with the Schema Registry can be supplied using none-prefixed, e.g. ssl.truststore.location, or prefixed e.g. ksql.schema.registry.ssl.truststore.location, names. 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 affects communication with Schema registry and overrides any non-prefixed setting of the same name.
Use the following to configure KSQL to communicate with the Schema Registry over HTTPS, where mutual authentication is not required and the Schema Registry’s SSL certificates are trusted by the JVM:
Use the following to configure KSQL to communicate with the 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 the 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 the Confluent 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.
The following are common configuration examples.
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.
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.
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.