using the kafka scripts in the bin directory

[aceeric]

All - I've configured a Strimzi 0.23.0 Kafka cluster with tls authentication:

...
listeners:
- name: tls
  port: 9093
  type: internal
  tls: true
  authentication:
    type: tls
authorization:
  simple
...

With this configuration, if I exec into a Kafka broker pod, I'd like to be able to use the various admin scripts in /opt/kafka/bin.

To do this I would expect to be able to use keytool to create a JKS keystore and truststore from the P12s referenced in /tmp/strimzi.properties and then reference those JKS files from a properties file like so:

cat <<EOF > /tmp/ssl.properties
bootstrap.servers=strimzi-kafka-bootstrap:9093
security.protocol=SSL
ssl.truststore.location=/tmp/my-truststore-from-p12.jks
ssl.truststore.password=foobar
ssl.truststore.type=JKS
ssl.keystore.location=/tmp/my-keystore-from-p12.jks
ssl.keystore.password=foobar
ssl.key.password=Jfoobar
ssl.keystore.type=JKS
EOF

Then:

bin/kafka-consumer-groups.sh --command-config /tmp/ssl.properties --bootstrap-server strimzi-kafka-bootstrap:9093 --all-groups --describe

I've tried many combinations of the P12 files referenced in the strimzi properties but can't make it work. It fails with various SSL exceptions. Has anyone done this and could provide some pointers? Thanks.

[scholzj]

This is not how it works and how you are supposed to use it. The best way is to create a regular user with the User Operator for example, start a separate pod (for example using the Kafka Strimzi image which already has Kafka, but even with a custom image with any tools you might need of course) and connect from there. You would be probably able to hack it from directly inside the pod, but since that is not expected to be done that way, there is no guide or anything.

[aceeric]

Thank you - yes this in fact was my original approach and it works fine: I create a KafkaUser:

cat <<EOF | kubectl apply -f -
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: clusteradmin
  labels:
    strimzi.io/cluster: strimzi
spec:
  authentication:
    type: scram-sha-512
EOF

and designate that user as a super user in the Kafka CR:

...
authorization:
  type: simple
  superUsers:
  - clusteradmin
...

Also enable SASL in the Kafka CR:

...
listeners:
- name: saslplain
  port: 9092
  type: internal
  tls: false
  authentication:
    type: scram-sha-512
...

Then use the generated password from the KafkaUser generated secret to configure a properties and JAAS file in an ephemeral pod creating using the strimzi-kafka:0.23.0-kafka-2.7.0 image:

cat <<EOF > config.conf
KafkaClient {
    org.apache.kafka.common.security.scram.ScramLoginModule required
    username="clusteradmin"
    password="tkFkgBPgRdZM";
};
EOF

cat <<EOF > config.properties
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-512
EOF

Then:

export KAFKA_OPTS="-Djava.security.auth.login.config=/path/to/config.conf"
bin/kafka-topics.sh --command-config /path/to/config.properties --list --bootstrap-server strimzi-kafka-bootstrap:9092

So that was all good and could be done with SSL or SASL SSL, I just chose SASL PLAIN. However after getting this going it occurred to me that all the TLS payloads were already there in cluster and must be being used anyways by the brokers to talk to each other and so I thought it must be possible to use those TLS materials rather than generate new credentials.

But I hear you - this is not the intent so - I'll move ahead with what I originally got working. Thank you for responding.