[Bug]: local keystore passwords appear in the process table

[freedge]

Bug Description

on clusters running kafka deployments deployed with strimzi-operator, we find various processes called with a password as argument. The password appears in the process table and is recorded by auditing tools

Steps to reproduce

1. deploy a kafka cluster with strimzi
2. observe the cluster through stackrox

Expected behavior

no password appearing on the command line

Strimzi version

strimzi-cluster-operator.v0.40.0

Kubernetes version

OpenShift 4.14

Installation method

from community operators

Infrastructure

Bare-metal

Configuration files and logs

No response

Additional context

example of code passing a password as argument to a process: https://github.com/strimzi/strimzi-kafka-operator/blob/4e8f6e45b0f81fd73be07890b05686562620229f/topic-operator/scripts/tls_prepare_certificates.sh#L19

processes found by stackrox:

 frigo     | zookeeper      | openssl     | pkcs12 -export -in /opt/kafka/zookeeper-node-certs/my-second-cluster-zookeeper-1.crt -inkey /opt/kafka/zookeeper-node-certs/my-second-cluster-zookeeper-1.key -chain -CAfile /opt/kafka/cluster-ca-certs/ca.crt -name my-second-cluster-zookeeper-1 -password pass:V0JM6KjQSw12rpep... -out /tmp/zookeeper/cluster.keystore.p12
 -certpbe aes-128-cbc -keypbe aes-128-cbc -macalg sha256

 frigo     | zookeeper      | keytool     | -keystore /tmp/zookeeper/cluster.truststore.p12 -storepass 2UwZDzZFaPqtOmoRD9Tmb-1fkdY... -noprompt -alias ca -import -file /opt/kafka/cluster
-ca-certs/ca.crt -storetype PKCS12

 frigo     | topic-operator | keytool     | -keystore /tmp/topic-operator/replication.truststore.p12 -storepass 9D1_RpQQJoWJhSTcoVvhqqynkc9... -noprompt -alias ca -import -file /etc/tls-
sidecar/cluster-ca-certs/ca.crt -storetype PKCS12

[scholzj]

These are the passwords generated at pod startup and used for the PKCS12 stores used by the ZooKeeper / Kafka. They will be also stored in their configuration files. Plus the original PEM files are mounted from the secrets next to them. So I do not think these passwords really leak anything secret that you cannot otherwise obtain.

[freedge]

for example a pod running as user nobody on the node, and started with hostPID=true (such as a node exporter pod for example) would be able to see the password when running a ps a the right time. It does not have access to the configuration files or PEM files or secret or mounts from strimzi pods, but it can obtain the secret from the process table.

[scholzj]

for example a pod running as user nobody on the node, and started with hostPID=true (such as a node exporter pod for example) would be able to see the password when running a ps a the right time. It does not have access to the configuration files or PEM files or secret or mounts from strimzi pods, but it can obtain the secret from the process table.

Sure. But the passwords are generated at the container startup and used for the PKCS12 files generated in the container. So you need to access the PKCS12 files in the container to use the passwords and if you can do that, you have the password anyway in the config file next to it.

I do not have a problem if anyone wants to improve this. But want to make it more clear what these passwords are.

[scholzj]

Discussed on the community call on 18.4.: As explained above, this is not a real security issue. But would be nice to have it fixed.

@freedge do you plan to contribute this? Or can someone else look into it?

[freedge]

hi, not really. (I made a list of findings and this one is at the bottom since it's not really an issue). Also it's not super trivial, in addition to fixing a bunch of scripts, https://github.com/strimzi/strimzi-kafka-operator/blob/51442a7acb8e81e14b8a4b7a066cad4e909b3bab/kafka-agent/src/main/java/io/strimzi/kafka/agent/KafkaAgent.java#L452 will need a new way to pass a password. It would be nice if there was no password appearing though, that would make the overall environment easier to audit (but, not safer).