Configuring security for Siren Federate

The Siren Federate plugin is compatible with Search Guard and Elastic Stack Security security systems. Follow the instructions to configure one of these solutions for Siren Federate. A security system maps a user to one or more roles. A role grants one or more permissions, for example, the sysadmin role.

A permission maps a role to one or more actions. An action specifies a type of request that operates at the index or cluster level. An action is identified by a unique identifier, for example, indices:data/read/mget, which identifies the multi get action.

An action follows the schema [cluster|indices]:<a path delimited by />; for example, cluster:internal/federate/* or indices:data/read/mget.

The following Siren Federate actions can be used to limit cluster or index requests:

  • indices:admin/federate: The prefix for actions that are related to the administration of internal Siren Federate indices.

  • indices:data/read/federate: The prefix for actions that are related to reading the index. Grant permissions for these actions to users with read access to an index.

    1. Grants permission to read index metadata, such as field mapping.

  • cluster:monitor/federate: The prefix for actions that are related to cluster monitoring.

  • cluster:admin/federate: The prefix for actions that are related to Siren Federate administration.

  • cluster:internal/federate: The prefix for all internal actions. Grant permissions for these actions to any user of Siren Federate.

Examples of roles in Siren Federate

To get started, you can create three generic roles in Siren Federate. In a later section, there are examples of how to implement the roles for the different security systems.

For every Siren Federate user, it is required to grant cluster-level permission for internal Siren Federate actions.

The System role

The System role manages the internal Siren Federate indices that store datasource and ingestion configurations. The following actions can be used for this role: - cluster:monitor/* - cluster:admin/* - indices:data/read*

For datasources and ingestion, the permissions must be granted on the master nodes.

The Admin role

The Admin role performs all actions related to administration, such as managing the license, the datasource, the virtual indices, and the ingestion jobs. The Admin role grants permissions for Siren Federate cluster administration and monitoring.

To manage, search, and read datasources and virtual indices, grant the following cluster-level and index-level permissions: - cluster:admin/federate/connector/* - indices:admin/federate/connector/* - indices:admin/mappings/federate/connector/* - indices:data/read/federate/connector/*

When a virtual index is defined, Siren Federate ensures that a concrete index exists with the same name for inter-operability with security system plugins. For this reason, you must set the following index-level write permissions: - indices:data/write*

To simplify the management of virtual indices, use a naming scheme to name them, such as virtual-*. You can then grant write permissions to all indices named `virtual-* collectively.

To manage the license, set the following cluster-level and index-level permissions: - cluster:admin/federate/license/*

To manage the ingestion jobs, set the following permissions: - cluster:internal/federate/connector/ingestion/* - cluster:admin/federate/connector/ingestion/* - cluster:admin/ingest/pipeline/put - cluster:admin/ingest/pipeline/delete

  • indices:admin/create

  • indices:admin/exists

  • indices:admin/mapping/put

The User role

The User role performs read-only actions on indices. This is required to execute a Siren Federate search request on one or more indices (virtual or actual). To search virtual indices, set the following user permissions: - indices:data/read/federate/connector/*

To search indices, set the following user permissions: - indices:data/read/*

These permissions allow the User role to read index metadata. This is required, because the Siren Federate query engine accesses index schema metadata by using indices:admin/mappings/fields/get during the query evaluation.

For datasources, these are the permissions needed: - indices:data/read/federate/connector/*

Set the following permissions for ingestion jobs: - cluster:admin/ingest/pipeline/get - cluster:admin/federate/connector/ingestion/get - cluster:admin/federate/connector/ingestion/run - cluster:admin/federate/connector/ingestion/search - cluster:internal/federate/connector/datasource/get - cluster:internal/federate/connector/ingestion/get

  • indices:admin/mappings/fields/get

  • indices:data/read/get

  • indices:data/read/search

Securing the connector

When a security system is configured, Siren Federate needs to authenticate as a user with all of the permissions on the indices that store datasources and virtual indices configurations.

The credentials of this user can be specified by setting the following node configurations:

  • siren.connector.username: The username of the Siren Federate system user.

  • siren.connector.password: The password of the Siren Federate system user.

Then create a user with that role, for example, a user called federate_system_user.

Master node in a cluster with authentication and federate_system_user user:

=== .elasticsearch.yml

siren.connector.username: federate_system_user
siren.connector.password: password
siren.connector.encryption.secret_key: "1zxtIE6/EkAKap+5OsPWRw=="

===

After you set the appropriate configuration parameters, restart the nodes.

Write operations are made on the virtual index, not against the actual datasource.

Examples of security system configurations