Chef has recently released Automate 4.x, this new version makes use of OpenSearch replacing Elasticsearch
Automate also allows for the use of external OpenSearch in 4.x and external Elasticsearch in 2.x and 3.x as outlined in the docs below
What I believe is not noted, is if you forgo the SSL certs on these setups, Elasticsearch will Default to having NO SSL in place, but with OpenSearch, the Default is SSL on.
for reference, chef automate also allows for external Postgres, as outlined in the docs below
a notable difference in the external Postgres is the ability to control the use of SSL with the following flag
# To use postgres with SSL, Set enable = true then, uncomment root_cert and fill out the certificate value.
enable = false
# root_cert = """$(cat </path/to/root/cert.pem>)"""
This is not present in the external OpenSearch configuration.
Ideally, the above tokenization in the TOML for Postgres makes sense, so replication of this for OpenSearch, ideally something like the following,
enable = false
However, this is not in place at the moment as shown in testing
chef-automate config patch patch.toml
ConfigError: The configuration is invalid: Config file must be a valid automate config: unknown configuration key "global.v1.external.opensearch.ssl.enable"
enable = true SSL should work as expected requiring the root_cert, however when
enable = false SSL should not be in use for communication
This is required for organisations that have been previously happy with the non-SSL traffic and will experience breaking in their Automate systems when upon in-place upgrades
This is also critical for testing in many organisations that don't want to have to deploy root certs across DEV/TEST and ephemeral environments.
Further to this, as it's present for the external Postgres, it seems odd not to replicate this functionality for all external items.