Connect to Kafka From Your Computer

This page shows how to list topics, read messages or test a client against
Kafka from your own machine, for debugging rather than for running applications.

Kafka on PushOps only accepts encrypted, authenticated connections: SASL_SSL
with SCRAM-SHA-512 on port 9093. Port 9092 is not open, so a client pointed at
localhost:9092 will never connect. Every connection needs three things: the
cluster's CA certificate, a Kafka user's credentials (a JAAS configuration),
and a network path to every broker.

There are two ways to get there:

Before you start

1. Raise an access request in SVIEW for your Kafka access role and get it
   approved — see Access Requests. Kafka is a shared
   service, so you can raise the request from any application in the
   Environment.

2. Log in to the cluster through Teleport:

   Shell

   tsh login --user <your-email> --proxy https://teleport.manage.cto2b.eu
   tsh kube login <your-cluster-name>

The access role gives you a namespace that holds a Kafka debug pod and the
Kafka CA certificate. The examples below call it <your-namespace>. The Kafka
cluster itself runs in its own namespace, usually kafka, and its instance
name is usually shared; both appear in the Kafka Component in SVIEW.

Option 1: use the Kafka debug pod

The debug pod already has the CA truststore, a Kafka user's credentials and the
bootstrap address set, so nothing has to be installed locally.

1. Find the pod:

   Shell

   kubectl get pods -n <your-namespace> | grep kafka-debug

2. Open a shell in it:

   Shell

   kubectl exec -it <kafka-debug-pod-name> -n <your-namespace> -c kafka-debug -- /bin/bash

3. List the topics the debug user can see:

   Shell

   ./kafka-topics.sh --list --bootstrap-server "$KAFKA_BOOTSTRAP_SERVERS" --command-config ../config/client_sasl.properties

The debug pod connects as its own Kafka user, so it sees only the topics that
user's ACLs allow. If a topic you expect is missing, check the ACLs — see
Kafka Users, Topic Names and ACL Roles.

Option 2: port forwarding from your machine

Why every broker needs its own forward

A Kafka client first contacts the bootstrap address, which replies with the
address of each broker, and the client then connects to those brokers
directly. Forwarding only the bootstrap service gets you past the first step
and then the client hangs, because the broker addresses it was given do not
resolve on your machine. The steps below make each broker address resolve to
its own local forward.

1. Get the CA certificate

kubectl get secrets -n <your-namespace> | grep kafka-acl-cert
kubectl get secret <kafka-acl-cert-secret> -n <your-namespace> \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > ~/kafka/ca.crt

Java clients, including the Kafka CLI tools, need it in a truststore:

keytool -importcert -alias kafka-ca -keystore ~/kafka/truststore.jks \
  -storepass "$TRUSTSTORE_PASSWORD" -file ~/kafka/ca.crt -noprompt

2. Get the Kafka user's JAAS configuration

Each Kafka user has a secret named sview-kafka-<stage>-<tenant>-<user>-user.
Use the user whose access you want to test:

kubectl get secrets -n <your-namespace> | grep sview-kafka-
kubectl get secret <sview-kafka-secret> -n <your-namespace> \
  -o jsonpath='{.data.sasl\.jaas\.config}' | base64 -d > ~/kafka/user_jaas.conf

3. Make the broker addresses resolve locally

List the broker pods. A production cluster usually has three, a light
non-production cluster one:

kubectl get pods -n kafka | grep broker

Add one line per address to /etc/hosts, giving the bootstrap address
127.0.0.1 and each broker its own loopback address. For an instance named
shared in the kafka namespace:

127.0.0.1 kafka-shared-kafka-bootstrap.kafka.svc
127.0.0.2 kafka-shared-broker-0.kafka-shared-kafka-brokers.kafka.svc
127.0.0.3 kafka-shared-broker-1.kafka-shared-kafka-brokers.kafka.svc
127.0.0.4 kafka-shared-broker-2.kafka-shared-kafka-brokers.kafka.svc

On macOS, the extra loopback addresses must be created first (until the next
reboot). Linux already answers on the whole 127.0.0.0/8 range, so skip this
there:

sudo ifconfig lo0 alias 127.0.0.2 up
sudo ifconfig lo0 alias 127.0.0.3 up
sudo ifconfig lo0 alias 127.0.0.4 up

4. Start the port forwards

Each command keeps running, so use one terminal tab per forward (or forward
the pods from k9s):

kubectl port-forward svc/kafka-shared-kafka-bootstrap -n kafka 9093:9093
kubectl port-forward --address 127.0.0.2 kafka-shared-broker-0 -n kafka 9093:9093
kubectl port-forward --address 127.0.0.3 kafka-shared-broker-1 -n kafka 9093:9093
kubectl port-forward --address 127.0.0.4 kafka-shared-broker-2 -n kafka 9093:9093

5. Connect a client

Create a client properties file, ~/kafka/client_sasl.properties:

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
ssl.truststore.location=/Users/<you>/kafka/truststore.jks
ssl.truststore.password=<the password you chose in step 1>

Then point the client at the bootstrap forward and the JAAS file. With the
Kafka CLI tools from the Apache Kafka download:

export KAFKA_OPTS="-Djava.security.auth.login.config=$HOME/kafka/user_jaas.conf"
./kafka-topics.sh --list --bootstrap-server 127.0.0.1:9093 \
  --command-config ~/kafka/client_sasl.properties

Your own application uses the same settings: bootstrap 127.0.0.1:9093,
SASL_SSL, SCRAM-SHA-512, the CA certificate, and the user's credentials.

6. Clean up

Stop the port forwards, remove the lines you added to /etc/hosts, and delete
the JAAS file.

Troubleshooting

If the issue persists, raise a request with the Environment, the Kafka user
you are connecting as, and the exact client error.

Related articles

• Kafka Access, ACLs and Topics
• Kafka Users, Topic Names and ACL Roles
• Access Requests
• Namespace Access