Step‑by‑Step Guide to Deploying Search Guard Security Plugin for Elasticsearch 5.x

1. Background

With the rapid growth of big‑data technologies, Elasticsearch has become the de‑facto engine for real‑time log analysis, but using it to store sensitive data without built‑in security poses serious access‑control risks.

The article evaluates the two available security plugins (Shield – commercial, and Search Guard – open source) and provides a practical guide for deploying Search Guard.

2. Installation

Download the matching Search Guard package for Elasticsearch 5.1.1:

https://search.maven.org/remotecontent?filepath=com/floragunn/search-guard-5/5.1.1-11/search-guard-5-5.1.1-11.zip

Install it with the Elasticsearch plugin command:

bin/elasticsearch-plugin install file:///search-guard-5-5.1.1-11.zip

3. Certificate Generation

Download the SSL scripts, unzip, and run the provided scripts to create a root CA, node keystores, and truststores. Example commands:

./gen_root_ca.sh ca_password truststore_password

./gen_node_cert.sh node_number keystore_password ca_password

./gen_client_node_cert.sh node_name keystore_password ca_password

Copy the generated truststore.jks and xxxkeystore.jks to each node’s conf directory.

4. Elasticsearch Configuration

Add the following entries to elasticsearch.yml (replace placeholders with actual file names and passwords):

searchguard.authcz.admin_dn: -cn=admin,ou=Test,ou=ou,dc=company,dc=com
searchguard.ssl.transport.keystore_filepath: xxxkeystore.jks
searchguard.ssl.transport.keystore_password: keystorepassword
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.truststore_password: truststorepassword
searchguard.ssl.transport.enforce_hostname_verification: false

Restart the Elasticsearch service.

5. Search Guard Configuration Files

The plugin uses five YAML files located under plugins/search-guard-5/sgconfig :

sg_config.yml – overall feature configuration.

sg_internal_users.yml – local user definitions with password hashes.

sg_roles.yml – role definitions (e.g., kibana5, logstash).

sg_roles_mapping.yml – maps users to roles.

sg_action_groups.yml – groups of actions to simplify role definitions.

6. Load Configuration

Synchronise the configuration to the cluster from any node using the sgadmin tool:

plugins/search-guard-5/tools/sgadmin.sh -cntestcluster -cd plugins/search-guard-5/sgconfig/ -ks config/node-0-keystore.jks -ts config/truststore.jks -nhnv

Only one node needs to run this command; user‑permission changes do not require a cluster restart.

7. Logstash Configuration

Configure the Logstash output to use the Search Guard user:

output {
  elasticsearch {
    user => "logstash"
    password => "logstash"
    ...
  }
}

Corresponding role and mapping are defined in sg_roles.yml and sg_roles_mapping.yml .

8. Kibana Configuration

Set the Kibana server credentials in kibana.yml and configure the Search Guard authentication domain in sg_config.yml (basic HTTP auth, internal backend).

9. Performance Test

Using esrally , the author compared a baseline cluster (no Search Guard) with a protected cluster. Results show a noticeable drop in throughput and increased latency when RPC encryption is enabled.

10. Conclusion

Search Guard provides essential index‑level access control for Elasticsearch clusters with a moderate performance impact; it is a viable open‑source option for environments requiring fine‑grained security.