Setting up Connection to Kafka
Required ACLs
The following Kafka ACLs are required by the Striim Kafka Writer service account. If you are connecting to Amazon MSK, see the IAM-based Required ACLs under Writing to AWS MSK instead:
Required Condition | Topic ACLs | Cluster ACLs | Transactional ID ACLs | Additional Notes |
|---|---|---|---|---|
Always | For Data Topics: WRITE, DESCRIBE (DESCRIBE is implicitly derived from WRITE) | DESCRIBE_CONFIGS | ||
When AutoCreateTopic=true | DESCRIBE_CONFIGS | CREATE | ||
When E1P=true | For Checkpoint Topics: READ, DESCRIBE, DESCRIBE_CONFIG, WRITE, DELETE | IDEMPOTENT_WRITE (only required for Kafka versions less than 2.8) | WRITE, DESCRIBE | Default Checkpoint Topic Format: <namespace>.TARGET.<componentName>_CHECKPOINT. Default Transactional ID Format: <namespace>.TARGET.<componentName>_<Current_Timestamp> (use a prefix-based pattern because the timestamp portion is dynamically generated). |
Supported Authentication Mechanisms
SASL Authentication methods:
PLAIN
GSSAPI (Kerberos)
SCRAM_SHA_256
SCRAM_SHA_512
Mutual TLS
None (Not recommended except for test environments)
AWS_MSK_IAM (Only for AWS MSK)
Using SASL Authentication
Kafka supports several SASL-based authentication mechanisms. All require specifying a JAAS configuration string in the Kafka Connection Profile.
SASL/PLAIN
SASL/PLAIN is a simple authentication mechanism that sends the username and password (base64-encoded). It is the simplest SASL method but requires SSL/TLS for security over the network.
Configure the Kafka Connection Profile with PLAIN authentication:
Property Name | Value |
|---|---|
Authentication Type | PLAIN |
Use SSL | True (recommended --- required when connecting to Confluent Cloud) |
Use Certificate | True (recommended) or False |
CA Certificate | Path to PEM file (if Use Certificate is true) |
SSL Truststore Location | Path to truststore file (if Use Certificate is false) |
SSL Truststore Password | Truststore password (if applicable) |
JAAS Config | See format below |
JAAS Config string format:
org.apache.kafka.common.security.plain.PlainLoginModule required username="<username>" password="<password>";
Replace <username> and <password> with valid credentials configured on the Kafka broker.
Note
Store the JAAS Config in the Striim Vault and reference the vault key in the JAAS Config property for security.
For Confluent Cloud Kafka, use the API Key as the username and API Secret as the password:
Property Name | Value |
|---|---|
Broker Address | pkc-xxxxx.us-central1.gcp.confluent.cloud:9092 |
Authentication Type | PLAIN |
Use SSL | True (always required for Confluent Cloud) |
JAAS Config | org.apache.kafka.common.security.plain.PlainLoginModule required username="<<API_KEY>>" password="<<API_SECRET>>"; |
SASL/GSSAPI (Kerberos)
SASL/GSSAPI uses Kerberos for authentication --- an enterprise-grade, ticket-based authentication protocol. It provides strong security without sending passwords over the network.
JAAS Config string format:
com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true storeKey=true keyTab="/etc/security/keytabs/kafka-client.keytab" principal="kafka-client@EXAMPLE.COM";
Replace the keyTab and principal values with your actual client keytab path and Kerberos principal.
SASL/SCRAM-SHA-256
SASL/SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism) is a secure password-based authentication that does not send passwords over the network. It is more secure than SASL/PLAIN and simpler than Kerberos.
JAAS Config string format:
org.apache.kafka.common.security.scram.ScramLoginModule required username="<username>" password="<password>";
Replace <username> and <password> with valid credentials configured on the Kafka broker.
SASL/SCRAM-SHA-512
SASL/SCRAM-SHA-512 is identical to SCRAM-SHA-256 but uses the SHA-512 hashing algorithm, providing stronger cryptographic security with longer hash outputs.
JAAS Config string format:
org.apache.kafka.common.security.scram.ScramLoginModule required username="<username>" password="<password>";
Replace <username> and <password> with valid credentials configured on the Kafka broker.
Combining SASL with SSL Encryption
Kafka supports combining SASL-based authentication with SSL/TLS encryption to ensure both secure identity verification and encrypted communication. Enable the Use SSL toggle along with any SASL mechanism (PLAIN, SCRAM_SHA_256, SCRAM_SHA_512, or GSSAPI).
Property Name | Value |
|---|---|
Authentication Type | PLAIN, SCRAM_SHA_256, SCRAM_SHA_512, or GSSAPI |
Use SSL | True |
Use Certificate | True (recommended) or False |
CA Certificate | Path to PEM file (if Use Certificate is true) |
SSL Truststore Location | Path to truststore file (if Use Certificate is false) |
SSL Truststore Password | Truststore password (if applicable) |
JAAS Config | Specify based on the SASL mechanism used |
Note
Store the JAAS Config and CA Certificate in the Striim Vault and reference vault keys in the respective properties.
Using Mutual TLS
Striim supports seamless certificate rotation to maintain secure communication. New server and client certificate pairs can be generated and applied to a Kafka Connection Profile even while applications using the profile are running.
Configure Self-Managed Kafka with mTLS
Step 1: Create a Certificate Authority (CA)
# Generate CA private key openssl genrsa -aes256 -out ca-key.pem 4096 # Create self-signed CA certificate openssl req -x509 -new -key ca-key.pem -sha256 -days 1826 -out ca-cert.pem
Step 2: Create and sign a Server Certificate
Create Server Certificate Configuration
Create server.conf with the certificate details and SAN entries:
Sample configuration
[req] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [req_distinguished_name] C = US ST = State L = City O = Organization OU = OrgUnit CN = kafka-server [v3_req] keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth,clientAuth subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = kafka-server DNS.3 = your-hostname.com IP.1 = 127.0.0.1 IP.2 = 192.168.1.100
NOTE : In alt_names section add the IP or the Domain where the server is hosted
Generate Server private key
openssl genpkey -algorithm RSA -out server.key -aes256
Create Certificate Signing Request
openssl req -new -key server.key -out server.csr -config server.conf
Create extension file
Create server.ext (defines SAN usage, same as config).
Sample configuration
authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth,clientAuth subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = kafka-server DNS.3 = your-hostname.com IP.1 = 127.0.0.1 IP.2 = 192.168.1.100
Create server certificate
openssl x509 -req -in server.csr \ -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \ -out server.crt -days 825 -sha256 -extfile server.ext
Step 3: Create Server Keystore and Truststore
# Keystore openssl pkcs12 -export -in server.crt -inkey server.key -certfile ca-cert.pem \ -out server.keystore.p12 -name kafka-server keytool -importkeystore -deststorepass <pass> -destkeypass <pass> \ -destkeystore server.keystore.jks -srckeystore server.keystore.p12 \ -srcstoretype PKCS12 -srcstorepass <p12-pass> -alias kafka-server # Truststore keytool -import -alias myCA -file ca-cert.pem -keystore server.truststore.jks
Step 4: Configure Kafka Broker for mTLS (server.properties):
listeners=SSL://localhost:9093 ssl.keystore.location=/path/to/kafka.server.keystore.jks ssl.keystore.password=serverpass ssl.key.password=serverkeypass ssl.truststore.location=/path/to/kafka.server.truststore.jks ssl.truststore.password=truststorepass ssl.client.auth=required
Step 5: Create a Client Certificate for Striim and configure the Kafka Connection Profile:
openssl genpkey -algorithm RSA -out client.key -aes256 openssl req -new -key client.key -out client.csr openssl x509 -req -in client.csr -CA ca-cert.pem -CAkey ca-key.pem \ -CAcreateserial -out client.crt -days 365 -sha256
Property Name | Value |
|---|---|
Authentication Type | Mutual TLS |
Use SSL | True |
Use Certificate | True (recommended for PEM-based files) or False (for JKS keystore/truststore) |
CA Certificate | Path to ca-cert.pem (if Use Certificate is true) |
SSL Keystore Certificate Chain | Path to client.crt (if Use Certificate is true) |
SSL Keystore Key | Path to client.key (if Use Certificate is true) |
SSL Key Password | Private key password if encrypted |
SSL Keystore Location | Path to client.keystore.jks (if Use Certificate is false) |
SSL Keystore Password | Keystore password (if Use Certificate is false) |
SSL Truststore Location | Path to client.truststore.jks (if Use Certificate is false) |
SSL Truststore Password | Truststore password (if Use Certificate is false) |
Note
For Striim SaaS deployments, generate the CA Certificate, SSL Keystore Certificate Chain, and SSL Keystore Key on an external machine, upload them to the Vault, and configure them in the Connection Profile properties.
Rotating Certificates
Rotated certificates are used by adapters when the adapter encounters an exception and retries, or on application restart. To rotate certificates:
Navigate to Manage Striim → Connection Profiles.
Locate the connection profile in use and click Edit.
Upload or reference the new certificate and key files.
Save the changes to apply the new certificates.
Configure Confluent Cloud Cluster with mTLS
Prerequisites:
A Confluent Cloud user with OrganizationAdmin role binding.
A Confluent Cloud cluster of type Dedicated.
Steps:
Upload your CA certificate to Confluent Cloud: navigate to Account & access → Workload identities → Add provider → Certificate Authority. Upload your ca-cert.pem file.
Create an Identity Pool within the Workload identities section.
Define Certificate Mapping Rules using Confluent's CEL (Common Expression Language) syntax, for example: CN == "STRIIM"
Generate the client certificate for Striim and configure the Connection Profile as described above (Use Certificate = True), uploading files to the Vault.