Environment variables not working

Hi,

What is described here does not seem to work at all for me

It doesn’t matter whether there is an .env file or whether the variables are set via export. Neither ${env.VAR_NAME} nor ${envbc.VAR_NAME} seem to work. Setting the values manually directly in the file works fine.

Any clue what could cause this?

Hi.

sgadmin replaces environment variables in-memory before uploading the configuration. The actual file contents are not changed. Configuration variables | Security for Elasticsearch | Search Guard

Do you see any error after sgadmin execution?
Any error in the Elasticsearch log?
Show me the sgadmin command you run?
What SG version do you use?

Hi,

I am aware. Env variables wouldn’t make any sense if sgadmin modifies the file.

The error is that the env variables are not used at all. I’m not sure what errors in elastic you’re looking for. The error is that the passwords do not work, neither the bcrypt ones, nor the cleartext ones in sg_config (e.g. for LDAP):

es01      | {"type": "server", "timestamp": "2020-08-04T06:07:01,609Z", "level": "WARN", "component": "c.f.s.a.BackendRegistry", "cluster.name": "jarvis-cluster", "node.name": "es01", "message": "Authentication finally failed for admin from 123.456.789.0:39212", "cluster.uuid": "Nqv_6mbTS5uXHpAU7Cq_EA", "node.id": "C87PAa1QSUK7N-aGjCpvqg"  }

examples:
sg_config.yml: password: ${env.LDAP_DN_PASS}
sg_internal_users: hash: ${envbc.ADMIN_PASS}

with ADMIN_PASS=abc in the environment.

Replacing those ${env.FOO} elements with their respective clear text and hashed passwords works perfectly fine. As I said above, I tried this with an .env file and setting the environment vars manually and checking with env if they exist.

Here is the answer to your other questions:

sh searchguard/search-guard-suite-plugin-7.8.1-43.0.0-sgadmin-standalone/tools/sgadmin.sh -icl -nhnv -h localhost -cd searchguard/ -cacert /etc/elasticsearch/certs/root-ca.pem -cert /etc/elasticsearch/certs/admin.pem -key /etc/elasticsearch/certs/admin.key

WARNING: JAVA_HOME not set, will use /bin/java
Search Guard Admin v7
Will connect to localhost:9300 ... done
Connected as CN=admin.jarvis,OU=Biocore,O=LCSB,DC=uni.lu
Elasticsearch Version: 7.8.1
Search Guard Version: 7.8.1-43.0.0
Contacting elasticsearch cluster 'elasticsearch' and wait for YELLOW clusterstate ...
Clustername: jarvis-cluster
Clusterstate: GREEN
Number of nodes: 10
Number of data nodes: 10
searchguard index already exists, so we do not need to create one.
Populate config from /root/jarvis-docker/searchguard
searchguard/sg_action_groups.yml OK
searchguard/sg_internal_users.yml OK
searchguard/sg_roles.yml OK
searchguard/sg_roles_mapping.yml OK
searchguard/sg_config.yml OK
searchguard/sg_tenants.yml OK
Will update '_doc/config' with searchguard/sg_config.yml 
   SUCC: Configuration for 'config' created or updated
Will update '_doc/roles' with searchguard/sg_roles.yml 
   SUCC: Configuration for 'roles' created or updated
Will update '_doc/rolesmapping' with searchguard/sg_roles_mapping.yml 
   SUCC: Configuration for 'rolesmapping' created or updated
Will update '_doc/internalusers' with searchguard/sg_internal_users.yml 
   SUCC: Configuration for 'internalusers' created or updated
Will update '_doc/actiongroups' with searchguard/sg_action_groups.yml 
   SUCC: Configuration for 'actiongroups' created or updated
Will update '_doc/tenants' with searchguard/sg_tenants.yml 
   SUCC: Configuration for 'tenants' created or updated
Done with success

Hi.
I gave it a shot and was able to reproduce the issue. We need some time to look into the issue deeper. I’ll get back to you soon. Thanks for reporting this.

1 Like

If you want to resolve the environment variables, use the -rev key.

$ ./sgadmin.sh --help
...
 -rev,--resolve-env-vars                        Resolve/Substitute env
                                                vars in config with their
                                                value before uploading

Hi,

thank you very much, that works!
May I suggest to put this more visible into the docs, especially into the concerning article?

Kind regards,
Sascha

Sure! We put it in the docs.