search

geonetwork / docker-geonetwork

Official Docker image repository for GeoNetwork
35 stars 39 forks source link

Removal of Elasticsearch environment variables means secrets have to be stored in code #120

Open digorgonzola opened 7 months ago

digorgonzola commented 7 months ago

Since v4.4 the individual environment variables for configuring Elasticsearch are obsolete. e.g. ES_HOST, ES_PORT, ES_PASSWORD etc.

This is a regression for us since we rely on passing secrets to individual environment variables from AWS secrets manager/parameter store using the "value_from" directive. See https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar-ssm-paramstore.html#secrets-envvar-ssm-paramstore-update-container-definition

Since we now have to pass all Geonetwork settings in the one variable GN_CONFIG_PROPERTIES it makes it necessary to store the secret for ES_PASSWORD in plain-text in code, unless we store all the values for GN_CONFIG_PROPERTIES as a secret too. However this becomes annoying as we ideally want to be able to look at the code to see what a particular environment is using.

Is there a good reason why these variables were deprecated?

fxprunayre commented 6 months ago

Is there a good reason why these variables were deprecated?

The main idea was to avoid to create one variable for each options and use Spring configuration as described in the doc (https://github.com/geonetwork/docker-geonetwork/tree/main/4.4.2) for all options instead of doing search/replace on startup (https://github.com/geonetwork/docker-geonetwork/blob/main/4.2.8/docker-entrypoint.sh#L30-L59). It also make configuration in docker the same as when deploying a WAR.

Maybe we can setup Spring var using env var directly ? or maybe use something similar to https://github.com/geonetwork/core-geonetwork/blob/main/pom.xml#L1486.

digorgonzola commented 6 months ago

Yep I would definitely vote for the use of environment variables just as you have for database configuration.