Kafka client.properties Generator
The client.properties that the Kafka command
line tools take with --command-config.
Connection and security only, with credentials referenced from a mounted
secret rather than written into the file.
client.properties
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Putting the password directly in the properties file
It lands in the file, in process listings, in container inspection and in any log that records configuration.
Instead:Use a config provider, or a JAAS file with restricted permissions.
Using SASL_PLAINTEXT with the PLAIN mechanism
SASL/PLAIN sends the password essentially in the clear. Without TLS it is readable on the wire.
Instead:SASL_SSL, or SCRAM which never transmits the password itself.
Reusing a broker properties file for a client
Broker and client settings look similar and are different files with different keys. A client reading a broker config silently ignores most of it.
Instead:Generate the client file separately.
The file every Kafka command line tool wants, and the flag it wants it under
Connection and security, nothing else. The hard parts are the JAAS line and the fact that the flag is different for each tool.
The flag is not consistent between tools
kafka-topics.sh, kafka-acls.sh, kafka-configs.sh and kafka-consumer-groups.sh take --command-config. kafka-console-consumer.sh takes --consumer.config and kafka-console-producer.sh takes --producer.config. Passing the wrong one is not always an error: some versions ignore the unknown flag, the tool then connects with no security configured at all, and the failure that follows is a timeout or an authorisation error that says nothing about the flag.
There is no password in the output
The generated file references a mounted secret through Kafka's own FileConfigProvider, and the commands to create that secret come with it. A client.properties sitting in a home directory or baked into an admin container image is a credential in a file nobody is tracking, and it is usually the one with the most permissions, because it is the file an operator uses. Two settings make the reference work, config.providers and config.providers.file.class, and both are always emitted: without them the reference silently resolves to the literal string rather than to the value.
The trailing semicolon on the JAAS line
sasl.jaas.config holds a JAAS login module entry, which has its own grammar and must end with a semicolon. Without it the tool fails to start and the exception mentions the JAAS configuration or the control flag rather than the missing character. It is the single most common mistake in a hand-written Kafka security config, and this generator cannot make it. For checking one you already have, the JAAS config decoder on this site reads it without printing the password.
This file holds nothing else, on purpose
No serializers, no group.id, no acks. A command line tool supplies its own, and adding them here is harmless and misleading: it reads as configuration in force when it is being ignored. For a real client, the producer and consumer config generators on this site emit those.
What this cannot see
It cannot verify that the secret file exists at the path given, that the credentials in it are correct, that the truststore contains the CA that signed your broker certificate, or that the principal has the ACLs it needs. Those are all runtime facts. What it can do is produce a file with the right shape, the right flag documented, and no credential inside it.