Release Date: 02.02.2021

New Features

API Auth Token Service

Search Guard 49 brings you the first general available version of the API Auth Token Service. This functionality allows you to create and manage API auth tokens that can be used to access Elasticsearch.

This is especially useful if you have applications which need authenticated access to Elasticsearch. Before the auth token service, you would have to give the application your full credentials, i.e., username and password. Now, you can create an auth token and just use this for authentication; it is also possible to limit the permissions the auth token is granted. Search Guard makes it easy to revoke the auth token at any time.

The auth token service is available in the Search Guard Kibana plugin and via a dedicated REST API.

The auth token service is disabled by default. To use it, you need to enable and configure it inside sg_config.yml.

The service is an enterprise feature. You can try it with the trial license that comes with a new Search Guard installation. If you want to use it for production purposes, you need an enterprise license.

More details:


Faster Bulk Actions

The privilege evaluation for bulk actions has been optimized. This yields a significant performance improvement for bulk actions; in some of our tests, we could double the throughput.

More information:

OIDC Authenticator Improvements

This release brings minor improvements to the OIDC auth functionality.

In some environments, ES can connect to IdP servers only via a proxy. For these scenarios, Search Guard introduces the new proxy option for http_authenticators of type oidc inside sg_config.yml.

This may look like this:

  http_enabled: true
  order: 0
    type: openid
    challenge: false
      subject_key: preferred_username
      roles_key: roles
      proxy: ""
    type: noop

Furthermore, with this release, the Kibana server will perform any communication with the IdP also via the Search Guard plugin. Thus, the Kibana configuration options searchguard.openid.connect_url, searchguard.openid.root_ca and searchguard.openid.verify_hostnames inside kibana.yml are no longer required and can be removed.

More information:

Using only a specific sub-string of a JWT, OIDC or SAML user as the Search Guard user

This release introduces the new configuration option subject_pattern for the JWT, OIDC and SAML authenticators. You can use this option to configure a regular expression which defines the expected format of the user name obtained from JWT tokens or SAML responses. If the user name does not match the pattern, authentication will fail. You can use capturing groups inside the regular expression to mark only certain parts to be used as the user name inside Search Guard.

For example, this can be used if your IdP provides user names in the format of email addresses. Using a subject_pattern with the value ^(.+)$ will then only use the local part of the email address as user name.

More information:


Blocked IPs and X-Forward-For addresses from proxies

The feature for blocking IPs did not work correctly when ES is only reachable by a proxy. While Search Guard can use IPs obtained from a X-Forward-For header for IP-based authentication (if xff is configured in sg_config.yml; see the documentation for details), IP blocking did not take such IPs into account.

This is now fixed; IPs considered for blocking are now the same IPs which are used for authentication.