Kantrip: switch kafka profiles like magic
Describe a Kafka cluster once, then run kcat, the Apache Kafka and
Confluent CLIs, Kaskade, kaf, or kcl against it with kantrip exec. Each
client gets its own config for that run, and the secrets stay in Kantrip's own vault in
your operating system's credential store.
pipx install kantriplatest release on GitHub
Pre-release, for macOS and Linux. Commands, output, and stored profiles may change before v0.1.0. See Releases.
A session, start to finish
Add a SCRAM profile over verified TLS, check it, create a topic with the Kafka CLIs, then list topics from a subshell. Inside the subshell, your prompt can show the active profile.
❯ kantrip add prod -b kafka.example.com:9093 --ca-file ./ca.pem --auth scram-sha-512 --username app
Kafka password:
Added profile 'prod': kafka.example.com:9093, tls, scram-sha-512
❯ kantrip ping prod
✅ Kafka transport: verified TLS; authentication: scram-sha-512 authenticated
❯ kantrip exec prod -- kafka-topics --create --topic payments --partitions 1 --replication-factor 1
Created topic payments.
❯ kantrip exec prod
prod ❯ kafka-topics --list
orders
payments
prod ❯ exit
❯ Why Kantrip
-
Secrets stay in the OS store
You type passwords and client secrets at a prompt that doesn't echo, and private keys are read from files. All of them go into Kantrip's own vault: a dedicated keychain on macOS, or a dedicated GNOME Keyring or KDE Wallet collection on Linux. They never appear in the profile, in command arguments, or in
describeoutput. -
One profile, every client
kcat, the Apache Kafka and Confluent CLIs, Confluent's Schema Registry consoles, Kaskade, kaf, and kcl each get their own config generated from the same profile. Arguments that would point them at another cluster are rejected.
-
Sessions clean up after themselves
Commands and Bash, Zsh, or Fish subshells run under Kantrip, which forwards signals and keeps the exit code. The session's files are deleted when it ends. If a crash leaves some behind, a later run or
kantrip doctor --repairremoves them.
Supported clients
kcatandkafkacat- Metadata, produce, and consume, including Confluent-compatible Avro.
- Apache Kafka and Confluent Platform CLIs
- Topics, console producer and consumer, consumer groups, configs, ACLs, and broker
API versions, with or without the
.shsuffix. - Confluent schema console clients
- Avro, JSON Schema, and Protobuf producers and consumers.
- Kaskade
adminandconsumer, with Confluent and native Apicurio decoding.kaf- Topics, consumer groups, produce, and consume, with Confluent-compatible Avro. No Kafka OAuth.
kcl- Topics, groups, cluster administration, produce, and consume, plus Confluent-compatible Registry administration, decoding, and encoding. No Kafka OAuth.
Kafka connections can be plaintext or verified TLS, with SASL/PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, mTLS, or OAuth. The Registry can be Confluent Schema Registry or Apicurio, and subshells can be Bash, Zsh, or Fish. The compatibility guide lists versions and limits.
Credential handling and its limits
What Kantrip does
- Its vault doesn't unlock when you log in, and Kantrip won't fall back to any other credential store.
- Profiles hold references to secrets, never the values;
doctorchecks that each secret is in the vault. - Kafka authentication requires verified TLS, and certificate and hostname checks can't be turned off.
- Client configuration goes into a private session directory, never into command arguments.
What it cannot do
- The client you run gets working credentials. Kantrip can't control what it does with them or what it prints.
- Malware running as your user, or anything that can read an unlocked or compromised credential store, can read your secrets.
kantrip pingshows that you can connect and authenticate, not that you can read topics, groups, or schemas.- A process that daemonizes escapes supervision, and whatever Kantrip gave it goes with it.
Read the threat model and report vulnerabilities privately through the security policy.
Thanks
