When using Kafka as a storage back-end, Jaeger before 1.18.1 writes plaintext and kerberos credentials to the container log files. A low privileged user could read the logs within the pod to discover the Kafka credentials as the information is disclosed as log-level info - which is the default. References: https://github.com/jaegertracing/jaeger/releases/tag/v1.18.1
Looks like the issue is located here: https://github.com/jaegertracing/jaeger/blob/e46f87376bdd2a28864864eb385ff49a6aa76330/plugin/storage/kafka/factory.go#L69 // Initialize implements storage.Factory func (f *Factory) Initialize(metricsFactory metrics.Factory, logger *zap.Logger) error { f.metricsFactory, f.logger = metricsFactory, logger logger.Info("Kafka factory", zap.Any("producer builder", f.Builder), zap.Any("topic", f.options.topic)) Logging f.Builder gets initialized a few lines before with f.options.Config which contains the credentials: https://github.com/jaegertracing/jaeger/blob/e46f87376bdd2a28864864eb385ff49a6aa76330/plugin/storage/kafka/factory.go#L62 // InitFromViper implements plugin.Configurable func (f *Factory) InitFromViper(v *viper.Viper) { f.options.InitFromViper(v) f.Builder = &f.options.config } The log file then looks like: {"level":"info","ts":1590031704.5821817,"msg":"Kafka factory","producer builder":{"Brokers":["127.0.0.1:9092"],"RequiredAcks":1,"Compression":0,"CompressionLevel":0,"ProtocolVersion":"","BatchLinger":0,"BatchSize":0,"BatchMaxMessages":0,"Authentication":"none","Kerberos":{"ServiceName":"kafka","Realm":"","UseKeyTab":false,"Username":"","Password":"","ConfigPath":"/etc/krb5.conf","KeyTabPath":"/etc/security/kafka.keytab"},"TLS":{"Enabled":false,"CAPath":"","CertPath":"","KeyPath":"","ServerName":"","ClientCAPath":"","SkipHostVerify":false},"PlainText":{"UserName":"root","Password":"password"}},"topic":"jaeger-spans"} So the issue isn't localized to just plain text auth but perhaps kerberos as well if used.
Whilst OpenShift ServiceMesh Jaeger does package the affected code (Kafka), the only supported storage backing is ElasticSearch. Additionally in the documentation/notes, only ElasticSearch is supported also - hence marking OSSM as affected but wontfix.
Acknowledgments: Name: Carl Henrik Lunde (SpareBank 1)
Statement: While OpenShift ServiceMesh Jaeger does package the affected code (Kafka), the only supported data store is ElasticSearch. Additionally, in the documentation and notes, only ElasticSearch is supported, marking OpenShift ServiceMesh as affected but WONTFIX.
Upstream release now available: https://github.com/jaegertracing/jaeger/releases/tag/v1.18.1
This issue has been addressed in the following products: Jaeger-1.17 Via RHSA-2020:2636 https://access.redhat.com/errata/RHSA-2020:2636
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-10750
External References: https://github.com/jaegertracing/jaeger/releases/tag/v1.18.1
Upstream patch: https://github.com/jaegertracing/jaeger/commit/360c38bec3f9718ebba7ddbf0b409b05995f3ace