Release Date: 02.02.2021
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
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.
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.
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
This may look like this:
openid_auth_domain: http_enabled: true order: 0 http_authenticator: type: openid challenge: false config: subject_key: preferred_username roles_key: roles openid_connect_url: https://keycloak.example.com:8080/auth/realms/master/.well-known/openid-configuration proxy: "https://proxy.example.com:9999" authentication_backend: 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
kibana.yml are no longer required and can be removed.
- Documentation for backend configuration
- Documentation for frontent configuration
- Merge request for backend
- Merge request for frontend
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
^(.+)@example.com$ will then only use the local part of the email address as user name.
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.