Search Guard FLX 1.2.0
Release Date: 2023-06-09
This is a new minor release of Search Guard FLX.
It brings some new features, some bug fixes and updates a number of dependencies.
Automatically selected auth methods for Kibana
If you are using more then one auth method for Kibana, you can now mark one of them as the default auth domain using the
auto_select attribute. Users opening Kibana will be then directed directly to the respective IdP for that auth method. Other auth methods are still available by predefined links.
Use negation in index patterns of Search Guard role definitions
You can now define index patterns like this in Search Guard role definitions:
example_role: index_permissions: - index_patterns: - "my_indices_*" - "-my_indices_secret" allowed_actions: - "*"
This allows you to give permissions to a certain set of indices matched by one pattern except for a subset matched by another pattern. The latter pattern is marked by prefixing a
- to it.
Support for Mustache templates for additional Signals features
You can now use Mustache templates to provide dynamic values for HTTP request headers which are used by webhook actions and HTTP inputs.
Signals email action: Use of real names in E-Mail addresses
The Signals email action allows you now to use real names in E-Mail addresses by using the syntax
Emily Example <[email protected]>.
Signals script compilations are no longer subject to rate limiting
Older versions of Signals could sometimes run into script compliation rate limits imposed by Elasticsearch. This was especially the case on installations with many watches. This rate limit does no longer apply to Signals.
Signals Kibana UI: Validation improvements
Validation errors in the Signals Kibana UI have been improved to be better readable and display more useful error messages instead of HTTP status codes.
Signals: Improved ack API
An additonal REST API for acknowleding actions has been created which returns the updated status as result.
Signals Log indices are now marked as hidden
.signals_log indices are now marked as hidden in the index settings. This avoids warnings from Elasticsearch.
Client certificate auth username mapping is now case insensitive
When using the
clientcert auth domain type, the JSON paths accessing information from the subject DN were accessing it in a case-sensitive fashion. However, RDNs can have varying cases, so a case-insensitive access was necessary.
- server.publicBaseUrl in conjunction with OIDC auth did not work
- Logo on login page was broken on Kibana 8
- Impersonation with sg_authc without user mapping failed
- See the complete changes in the Gitlab Milestone