| 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 96 changed one line |
| ssl.keystore.location=/Users/kz/crushftp/cert_or_keys/client.keystore.jks |
| #Server Settings: ssl.client.auth=required -Tells the broker to request and validate a client certificate during the SSL handshake. |
| ssl.keystore.location=/Users/crushftp/client.keystore.jks |
| At line 108 added 12 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.\\ |
| \\ |
| 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"; |
| At line 100 changed one line |
| }}} |
| # 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 |
| At line 102 changed one line |
| • sasl.mechanism: The SASL mechanism used. PLAIN is username/password-based authentication.\\ |
| # 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 104 changed 4 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.\\ |
| \\ |
| 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.\\ |
| ---- |
