Chef Ideas

Where we are

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

https://docs.chef.io/automate/elasticsearch/#configure-external-elasticsearch

https://docs.chef.io/automate/opensearch/#configure-external-opensearch

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

https://docs.chef.io/automate/postgresql/#configuring-an-external-postgresql-database

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. 
[global.v1.external.postgresql.ssl]
enable = false
# root_cert = """$(cat </path/to/root/cert.pem>)"""

This is not present in the external OpenSearch configuration.

what we need

Ideally, the above tokenization in the TOML for Postgres makes sense, so replication of this for OpenSearch, ideally something like the following,

[global.v1.external.opensearch.ssl]
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"

When enable = true SSL should work as expected requiring the root_cert, however when enable = false SSL should not be in use for communication

Reasoning and use cases

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.