Configuring Investigate to work with Search Guard Classic
This section describes the minimal configuration that is required to integrate a Siren Investigate instance with an Elasticsearch cluster that is configured as described in Search Guard Classic integration .
By convention, certificates and PKI-related files are stored in a
pki, which is located inside the directory where Siren Investigate was
Before you proceed with the configuration, create a
pki folder at the
same level as the
config folder, if it does not already exist and copy
the following files into it:
chain-ca.pem: a PEM encoded file containing a CA certificate bundle that can validate the certificates installed in the Elasticsearch cluster.
If you want to use the optional Search Guard Classic configuration UI, you must also copy the administrative certificate and key to this directory.
If required, it is possible to put PKI related files in any location that is readable by the user the Investigate process is running as. When copying the Search Guard Classic administrative certificates for use in Investigate, make sure they are not readable by everyone.
Make sure that the Investigate configuration file is only readable by the user Investigate is running as.
config/investigate.yml file to specify the credentials of the
sirenserver user, for example:
elasticsearch.username: 'sirenserver' elasticsearch.password: 'password'
Make sure that
elasticsearch.url starts with
https:// and that the correct
port is specified, for example:
To validate the Elasticsearch certificate, specify the path to the
CA bundle in
elasticsearch.ssl.certificateAuthorities and set
elasticsearch.ssl.verificationMode parameter to
certificate, for example:
elasticsearch.ssl.certificateAuthorities: 'pki/chain-ca.pem' elasticsearch.ssl.verificationMode: certificate
If your certificate configuration allows it, you can enable hostname verification
To enable authentication support in Siren Investigate, you must enable
investigate_access_control plugin and configure a few settings.
The following is an example of a minimal configuration:
investigate_access_control: enabled: true acl: enabled: true admin_role: investigate_admin backend: searchguard cookie: secure: true password: '12345678123456781234567812345678'
enabled: set to
acl.enabled: set to
admin_role: users with this role will be given full access to the Siren Investigate configuration sections.
backend: set to
cookie.password: A 32-character-long alphanumeric string that is used to derive the key that encrypts and signs cookies. Make sure to customize this password as it can be used to decrypt session cookies.
cookie.secure: if set to true, the cookie will be transmitted by the browser only if the request is being sent via HTTPS. Defaults to
Ensure that you personalize the session cookie password.
session.ttl: The lifetime of the session in milliseconds. If not set, the session will last as long as the session cookie is valid. Defaults to
session.keepAlive: If set to
true, every time a request is received within the session lifetime, the session lifetime will be extended by
session.ttl. Defaults to
session.idleLogoutTime: Allowed time of inactivity in milliseconds. If inactive for more than idleLogoutTime, the user will be automatically logged out. Defaults to
0means no automatic logout.
cookie.password: A 32 characters long alphanumeric string used to derive the key used to encrypt and sign cookies.
cookie.ttl: The lifetime of the session cookie in milliseconds. If not set, the cookie will expire when the browser is closed, which is the recommended setting. Note that browsers may not remove session cookies when a tab is closed or even across restarts, so you should set
session.ttlfor additional protection. Defaults to
cookie.name: The name of the session cookie. Defaults to
acl.index: The Elasticsearch index in which access control rules and saved objects metadata will be stored (
After you change the configuration file restart Siren Investigate. If the configuration is correct, an authentication dialog opens when the system restarts.
You can now log in as an user with the
investigate_admin role, for example,