Siren Platform User Guide

Siren Investigate certificates

Here we give an example of where to store client certificates and keystores on Siren Investigate. Note: These are examples for a fresh install using the TLS certificate generator.

In siren-investigate/pki (which was created earlier for https support) a new folder searchguard was created with the following:

  • CN=sgadmin.crtfull.pem: a certificate bundle with administrative privileges over the Search Guard Management REST API. Copied from client-certificates in TLS certificate generator bundle.
  • CN=sgadmin.key.pem: the key of the administrative certificate. Copied from client-certificates in TLS certificate generator bundle.
  • ca.pem: the cluster CA certificate chain in PEM format. Copy of root-ca.pem from top level folder TLS certificate generator bundle.
  • CN=sgadmin-keystore.jks: Keystore containing the admin certificate. Used with sgadmin. Copied from client-certificates in TLS certificate generator bundle.

The password of all Java keystores can be found in the README.txt from top level folder of TLS certificate generator bundle.

Search Guard configuration

A Search Guard configuration folder contains the following files:

  • sg_config.yml: General configuration.

  • sg_action_groups.yml: Named groups of permissions.

  • sg_roles.yml: Definition of roles.

  • sg_internal_users.yml: Search Guard internal user database.

  • sg_roles_mapping.yml: Mapping between users and roles.

The following sample configuration is used for Elasticsearch with no data, for example your own Elasticsearch or using our no-data-no-security package. Further examples are available in the config/sgconfig folder in the Elasticsearch instance included in the demonstration distribution; the contents of the files are explained in the next sections and can be used as a general guideline.

For additional configuration options, refer to the Search Guard documentation.

General configuration

sg_config.yml

searchguard:
  dynamic:
    respect_request_indices_options: true
    kibana:
      do_not_fail_on_forbidden: true
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
    authc:
      transport_auth_domain:
        enabled: true
        order: 2
        http_authenticator:
          type: basic
        authentication_backend:
          type: internal
      basic_internal_auth_domain:
        enabled: true
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern

The sg_config.yml file contains the configuration of the authentication mechanisms and backends; this configuration:

  • Switches off the anonymous role (anonymous_auth_enabled: false).

  • Switches off support for external proxies (xff.enabled: false).

  • Enables HTTP basic authentication on the internal Search Guard user database.

Action groups

sg_action_groups.yml

UNLIMITED:
  - "*"

###### INDEX LEVEL ######

INDICES_ALL:
  - "indices:*"

# for backward compatibility
ALL:
  - INDICES_ALL

MANAGE:
  - "indices:monitor/*"
  - "indices:admin/*"

# for backward compatibility
MONITOR:
  - MANAGE

WRITE:
  - "indices:data/write*"
  - "indices:admin/mapping/put"

READ:
  - "indices:data/read*"

VIEW_INDEX_METADATA:
  - "indices:admin/aliases/get"
  - "indices:admin/aliases/exists"
  - "indices:admin/get"
  - "indices:admin/exists"
  - "indices:admin/mappings/fields/get*"
  - "indices:admin/mappings/get*"
  - "indices:admin/mappings/federate/connector/get*"
  - "indices:admin/mappings/federate/connector/fields/get*"
  - "indices:admin/types/exists"
  - "indices:admin/validate/query"
  - "indices:monitor/settings/get"

###### CLUSTER LEVEL ######

CLUSTER_ALL:
  - "cluster:*"

CLUSTER_MONITOR:
  - "cluster:monitor/*"

CLUSTER_COMPOSITE_OPS:
  -  CLUSTER_COMPOSITE_OPS_RO
  - "indices:data/write/bulk"

CLUSTER_COMPOSITE_OPS_RO:
  - "indices:data/read/mget"
  - "indices:data/read/msearch"
  - "indices:data/read/mtv"
  - "indices:data/read/scroll*"

CLUSTER_MANAGE:
  - CLUSTER_INTERNAL_FEDERATE
  - "cluster:admin/federate/*"
  - "indices:admin/aliases*"

CLUSTER_INTERNAL_FEDERATE:
  - "cluster:internal/federate/*"

The file sg_action_groups.yml contains named groups of permissions which can be used in the role configuration file including Search Guard’s default groups and Siren Investigate specific groups. Groups are divided into cluster and indices levels.

Cluster-level groups
  • CLUSTER_ALL: all cluster-level actions.

  • CLUSTER_MONITOR: monitoring actions.

  • CLUSTER_COMPOSITE_OPS: Groups all the permissions to execute composite requests not recognized by Search Guard; the group has to be granted on all indices to roles that have access only to a subset of indices .

  • CLUSTER_INTERNAL_FEDERATE: actions specific to the internal workflow of Federate.

  • CLUSTER_MANAGE: in addition to CLUSTER_INTERNAL_FEDERATE this includes actions to manage its own internal indices.

Indices-level groups
  • INDICES_ALL: all indices-level actions.

  • MONITOR: all actions regarding index monitoring, e.g., recovery, segments info, index stats and status.

  • MANAGE: all monitor and index administration actions.

  • WRITE: actions to modify an index.

  • READ: actions to read and search an index.

  • VIEW_INDEX_METADATA: any action to retrieve metadata about an index, e.g., list of fields, get a setting.

Roles

sg_roles.yml

# Permissions for the investigate system user
investigate_system:
  cluster:
    - CLUSTER_COMPOSITE_OPS
    - CLUSTER_MANAGE
    - CLUSTER_MONITOR
  indices:
    '?siren*':
      '*':
        - INDICES_ALL
    '*':
      '*':
        - READ
        - VIEW_INDEX_METADATA

# Permissions for a Investigate administrator
investigate_admin:
  cluster:
    - CLUSTER_COMPOSITE_OPS_RO
    - CLUSTER_MANAGE
    - CLUSTER_MONITOR
  indices:
    '*':
      '*':
        - MANAGE
        - READ
        - VIEW_INDEX_METADATA

# Permissions for a Investigate regular user.
investigate_user:
  cluster:
    - CLUSTER_COMPOSITE_OPS_RO
    - CLUSTER_INTERNAL_FEDERATE
  indices:
    'data-*':
      '*':
        - READ
        - VIEW_INDEX_METADATA

A permission is defined by the following syntax:

<username>:
  <indices or cluster>:
    '<index name or regular expression>':
      '<type name or regular expression>':
        - <list of permissions or action group names>

The index name can contain the simple expansion characters * and ? to match any sequence of character/any single character; for further information about defining permissions, refer to the Search Guard configuration documentation.

This sample configuration defines the following roles:

  • investigate_system: Defines the permissions for the Siren Investigate server process, with read/write access to the internal Siren Investigate indices.

  • investigate_admin: Defines the permissions for a Siren Investigate user that has the administrator permissions. This user has permissions to upload the Siren Investigate license, get monitoring information from the cluster and managed JDBC datasources.

  • investigate_user: Defines the permissions for a Siren Investigate user with read only access to all indices whose name starts with data-*.

Users

sg_internal_users.yml

# Internal user database
# The hash value is a bcrypt hash and can be generated with plugin/tools/hash.sh
sirenserver:
  hash: $2a$12$zMeFc6Xi.pcgDVHsvtCV9ePNteVwTE5uGxcKdf7XQcKB9.VkD8iOy
sirenadmin:
  hash: $2a$12$zMeFc6Xi.pcgDVHsvtCV9ePNteVwTE5uGxcKdf7XQcKB9.VkD8iOy
sirenuser:
  hash: $2a$12$zMeFc6Xi.pcgDVHsvtCV9ePNteVwTE5uGxcKdf7XQcKB9.VkD8iOy

The file defines the credentials for Search Guard internal users; passwords are stored as hashes in the hash attribute beneath each username.

The password for all the accounts in the example is password.

To change the password of a user, you must generate the corresponding hash; this can be done by executing the plugins/search-guard-<version>/tools/hash.sh script as follows:

$ bash plugins/search-guard-6/tools/hash.sh -p password

The script will output the hash for the password specified after the -p switch.

It is also possible to change passwords for internal users from the Access Control application in the Siren Investigate UI once configured.

Role mappings

sg_roles_mapping.yml

investigate_system:
  users:
    - sirenserver

investigate_admin:
  users:
    - sirenadmin

investigate_user:
  users:
    - sirenuser

The file defines the list of users assigned to each role using the following form:

<role name>:
  users:
    - <username>
    - <username>
Uploading the configuration to the cluster

To upload the configuration defined in the previous steps, go to the Elasticsearch folder and execute the plugins/search-guard-<version>/tools/sgadmin.sh script as follows:

$ bash plugins/search-guard-6/tools/sgadmin.sh \
  -cd config/sgconfig \
  -cn siren-distribution \
  -ts config/truststore.jks \
  -tspass password \
  -ks ../siren-investigate/pki/searchguard/CN\=sgadmin-keystore.jks \
  -kspass password \
  -h localhost \
  -p 9330 \
  -nhnv

To reload the configuration you have to use the same command with the -rl flag instead of -cd, for example:

$ bash plugins/search-guard-6/tools/sgadmin.sh \
  -rl
  -cn siren-distribution \
  -ts config/truststore.jks \
  -tspass password \
  -ks ../siren-investigate/pki/searchguard/CN\=sgadmin-keystore.jks \
  -kspass password \
  -h localhost \
  -p 9330 \
  -nhnv

You must specify the following arguments based on your environment configuration:

  • -cd: Path to the folder containing the Search Guard access control configuration.
  • -cn: Name of the Elasticsearch cluster.
  • -ts: Path to the truststore file.
  • -tspass: Password of the truststore file.
  • -ks: Path to the administrative client certificate keystore.
  • -kspass: Password of the client certificate keystore file.
  • -h: Hostname of a node in the cluster.
  • -p: Transport port of the node specified in the -h option.
  • -nhnv: Switches off host name verification; remove this option if you installed node certificates with the correct hostname (recommended in production).
  • -rl: Reloads the configuration and flushes the internal cache.

By default, the number of replicas for the searchguard index will be set at creation time to the number of data nodes - 1.

For additional information on how to set replication settings and sgadmin in general, refer to http://floragunncom.github.io/search-guard-docs/sgadmin.html.

If the command is executed successfully, a list of the actions executed and their outcome will be printed on screen, for example:

Clustername: elasticsearch
Clusterstate: YELLOW
Number of nodes: 1
Number of data nodes: 1
searchguard index does not exists, attempt to create it ... done
Populate config from /elasticsearch/sg_config
Will update 'config' with sg_config/sg_config.yml
   SUCC: Configuration for 'config' created or updated
Will update 'roles' with sg_config/sg_roles.yml
   SUCC: Configuration for 'roles' created or updated
Will update 'rolesmapping' with sg_config/sg_roles_mapping.yml
   SUCC: Configuration for 'rolesmapping' created or updated
Will update 'internalusers' with sg_config/sg_internal_users.yml
   SUCC: Configuration for 'internalusers' created or updated
Will update 'actiongroups' with sg_config/sg_action_groups.yml
   SUCC: Configuration for 'actiongroups' created or updated
Done with success

You can then verify that SSL and authentication are enabled by making an authenticated request with wget, for example:

$ wget --ca-certificate=../siren-investigate/pki/searchguard/ca.pem --http-user=sirenserver --http-password=password -qO - https://localhost:9220

To display information about the certificate as seen by a client you can execute the following command:

$ echo | openssl s_client -servername localhost -connect localhost:9220 -showcerts | openssl x509 -text -inform pem -text -noout

Search results

    No results found