| At line 1 changed one line |
| !!Kafka task |
| !!!Kafka task |
| At line 57 changed one line |
| __ KafkaTask SASL properties Explained__:\\ |
| !! KafkaTask SASL properties Explained:\\ |
| At line 78 added 7 lines |
| __sasl.jaas.config__: |
| • sasl.jaas.config: The JAAS (Java Authentication and Authorization Service) configuration line to authenticate with Kafka using SASL/PLAIN.\\ |
| • username / password: ⚠️ Replace these with your actual Kafka credentials.\\ |
| \\ |
| ! Kafka Security Protocols:\\ |
| \\ |
| ---- |
| At line 86 added one line |
| ---- |
| At line 91 changed one line |
| ssl.truststore.location=/Users/kz/crushftp/cert_or_keys/kafka.server.truststore.jks |
| ssl.truststore.location=/Users/crushftp/kafka.server.truststore.jks |
| At line 97 changed one line |
| ssl.keystore.location=/Users/kz/crushftp/cert_or_keys/client.keystore.jks |
| ssl.keystore.location=/Users/crushftp/client.keystore.jks |
| At line 109 added 2 lines |
| ---- |
| • __SASL_SSL with SCRAM-SHA-512 mechanism__: This configuration provides strong security by combining __SSL__ encryption with __SCRAM-SHA-512__ authentication. SSL ensures encrypted communication between clients and brokers, while SCRAM-SHA-512 performs secure password-based authentication using salted, hashed credentials. It’s a preferred option for production environments requiring both confidentiality and strong identity verification without relying on plaintext passwords.\\ |
| At line 102 changed 3 lines |
| __sasl.jaas.config__: |
| • sasl.jaas.config: The JAAS (Java Authentication and Authorization Service) configuration line to authenticate with Kafka using SASL/PLAIN.\\ |
| • username / password: ⚠️ Replace these with your actual Kafka credentials.\\ |
| Example:\\ |
| {{{ |
| #Authentication related settings |
| security.protocol=SASL_SSL |
| sasl.mechanism=SCRAM-SHA-512 |
| sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \ |
| username="kafka-username" \ |
| password="kafka-password"; |
|
| # SSL Truststore (used to verify the Kafka server cert) |
| ssl.truststore.location=/Users/kz/crushftp/cert_or_keys/kafka.server.truststore.jks |
| ssl.truststore.password=truststorepass |
|
| # Optional: Only needed if mutual TLS is required |
| ssl.keystore.location=/Users/kz/crushftp/cert_or_keys/client.keystore.jks |
| ssl.keystore.password=clientpass |
| ssl.key.password=clientpass |
| }}} |
| ---- |
| • __SASL with GSSAPI / Kerberos__: SASL/GSSAPI leverages Kerberos to perform strong, mutual authentication: clients obtain a service ticket from the KDC and present it to the broker, eliminating the need to send passwords over the wire. Once authenticated, it can be combined with SSL to provide both encryption and integrity for all Kafka traffic. This mechanism is ideal in enterprise environments where centralized credential management and single‐sign‐on are required.\\ |
| At line 133 added 25 lines |
| When using CrushFTP’s KafkaTask with Kerberos, you can authenticate via a __keytab__. Example:\\ |
| {{{ |
| # Authentication related settings |
| security.protocol=SASL_SSL |
| sasl.mechanism=GSSAPI |
| sasl.kerberos.service.name=kafka |
| sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \ |
| useKeyTab=true \ |
| keyTab="/etc/security/kafka.keytab" \ |
| principal="kafka@LMINT.COM"; |
|
| # SSL Truststore (to verify the Kafka server cert) |
| ssl.truststore.location=/etc/security/kafka.server.truststore.jks |
| ssl.truststore.password=truststorepass |
|
| # Optional: mutual TLS if broker demands it |
| ssl.keystore.location=/etc/security/client.keystore.jks |
| ssl.keystore.password=clientpass |
| ssl.key.password=clientpass |
| }}}\\ |
| __Key points for GSSAPI / Kerberos setups__:\\ |
| 1. /etc/krb5.conf must define your realm and KDC.\\ |
| 2.Make sure your keytab contains the exact Kafka service principal (in our example kafka@LMINT.COM). Without that entry (and the correct KVNO [Wikipedia :Key Version Number Link|https://en.wikipedia.org/wiki/Kerberos_(protocol)#Key_Version_Number_(KVNO)]), the broker won’t be able to decrypt or verify incoming GSSAPI tickets.\\ |
| 3. When you enable ssl.client.auth=required on the broker, every client must present a valid TLS certificate during the handshake. Make sure each client has a keystore containing its private key and signed certificate, and a truststore that includes the CA (or broker) certificate, so both sides can authenticate and encrypt the connection -> SSL keystore/truststore files must exist and match your broker’s certificates.\\ |
| ---- |
