Open freephile opened 4 months ago
I believe it's entirely possible to bind Elasticsearch to an internal (loopback) interface for transport in production mode -- given that we only want to talk to Elasticsearch from MediaWiki and we do NOT want to expose an Elasticsearch service to anything else. And, we can set the discovery.type to 'single_node'. And, we can enforce the bootstrap checks which would otherwise be skipped in such a configuration. However, to do that, we need to set JVM options, and so we need a JVM options template.
This scenario builds on the minimal security requirements by adding transport Layer Security (TLS) for communication between nodes. This additional layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your Elasticsearch cluster.
Your external HTTP traffic between Elasticsearch and Kibana won’t be encrypted, but internode communication will be secured.
cd /usr/share/elasticsearch/
[root@localhost elasticsearch]# ls
bin jdk lib LICENSE.txt modules NOTICE.txt plugins README.asciidoc
[root@localhost elasticsearch]# ./bin/elasticsearch-setup-passwords auto
warning: usage of JAVA_HOME is deprecated, use ES_JAVA_HOME
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N]y
Changed password for user apm_system
PASSWORD apm_system = wKwa4Ksn5Aoe61xDZiL3
Changed password for user kibana_system
PASSWORD kibana_system = QnxlQbOCiHvKZyrB9whZ
Changed password for user kibana
PASSWORD kibana = QnxlQbOCiHvKZyrB9whZ
Changed password for user logstash_system
PASSWORD logstash_system = rXbyi0FBVkqRW6bstvTX
Changed password for user beats_system
PASSWORD beats_system = RQ8XlEIap0SlgcNTCs1n
Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = 3oVr9ELMcIA7LE2KNK0e
Changed password for user elastic
PASSWORD elastic = eApmGGeHMeJcn3ZuaBk5
To reduce this to an ansible role, we'll need to script the creation of the passwords for the 'elastic' and 'kibana_system' users (at least), and use the latter in kibana.yml in issue #59
For meza code this touches src/roles/mediawiki/templates/LocalSettings.php.j2
for wgCirrusSearchClusters
and also src/roles/elasticsearch/tasks/main.yml
where it uses the ansible.builtin.uri module for making a REST request to elasticsearch.
The src/playbooks/elasticsearch-upgrade.yml and src/roles/elasticsearch/tasks/es_upgrade.yml are also affected, but outside the scope of this issue since we're not working on an upgrade.
making an ad-hoc ansible command to test the HTTP-basic auth against Elasticsearch looks like this:
ansible localhost -m uri -a "url='http://localhost:9200' method=GET user=elastic password='eApmGGeHMeJcn3ZuaBk5'"
There are two levels that need to be addressed:
Elasticsearch Security
Elasticsearch has multiple layers of security from minimal to basic, basid+HTTPS
We need to establish at least the 'basic' level of security.
FIPS 140-2
The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), titled "Security Requirements for Cryptographic Modules" is a U.S. government computer security standard used to approve cryptographic modules. Elasticsearch offers a FIPS 140-2 compliant mode and as such can run in a FIPS 140-2 configured JVM.
On top of establishing baseline security for Elasticsearch as a service, we can and should also establish the necessary configuration to be FIPS 140-2 compliant.
See the info provided by Elastic.co on how to be FIPS 140-2 compliant.