On Mon, 10 Jan 2022 at 18:05, Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Mon, 10 Jan 2022 at 17:28, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2022-01-10 15:44:41 +0100 (+0100), Radosław Piliszek wrote:
On Mon, 10 Jan 2022 at 14:58, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2022-01-10 14:47:53 +0100 (+0100), Radosław Piliszek wrote: [...]
Yes, we have already patched the command line [1] so the guidance is to make sure to run the latest and greatest. It would make sense to broadcast this so that users know that log4j is in Elasticsearch. In Kolla, ES is used either standalone or with Monasca (and soon Venus).
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/821860 [...]
Is the presence/absence of Elasticsearch determined by configuration options, or is it always installed and run when Kolla is used?
Determined by configuration. It is not present by default - only if installed on demand, by enabling central logging, Monasca or some other dependent component.
Thanks for the details, and apologies for all the sudden questions. Is there a list of which components (aside from the aforementioned central logging and Monasca) which pull Elasticsearch into the deployment?
Yeah, I just omitted them as they are less frequently used: - osprofiler - skydive - cloudkitty configured to use elasticsearch backend
Also, does Kolla build/distribute its own Elasticsearch images or reuse some maintained by an outside party? And what version(s) of Elasticsearch and Log4j end up installed?
Kolla builds its own images using upstream (ES) rpm/deb packages. We end up with the latest 7.13.x as that's the last truly OSS release of ES. I know it has vulnerable log4j but can't tell the version atm. Let me know if it's crucial.
For CentOS images, this is bundled into elasticsearch-oss-7.10.2-1.x86_64: /usr/share/elasticsearch/lib/log4j-api-2.11.1.jar /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar Note that according to Elastic, this version is not vulnerable thanks to the use of the Java Security Manager.