Changelog for Search Guard 7.x-35.0.0
Release Date: 07.05.2019
Changes
- This version is based on 6.7.x-25.0 and contains all features from this version
- The code of the former standalone SSL Plugin was merged into the Search Guard codebase. So for Search Guard 7 the
search-guard-ssl
github repository is no longer relevant.
BREAKING: Support for document types and tribe nodes removed
Elasticsearch 7 does no longer support document types and tribe nodes. We removed those features now also from Search Guard.
Types were also removed from the auditlog.
BREAKING: Deprecated endpoints from REST management API removed
The following endpoints were removed:
/_searchguard/api/actiongroup/
# Use /_searchguard/api/actiongroups/ instead
/_searchguard/api/configuration/{configname}
# Use /_searchguard/api/{configname}/ instead
/_searchguard/api/user/
# Use /_searchguard/api/internalusers/ instead
BREAKING: New configuration format
With Search Guard 7 we introduce a new configuration format to fix a few longstanding issues and to remove the document type level security from it.
The new format is documented here:
- Search Guard Configuration
- Internal users
- Roles Mapping
- Action Groups
- Search Guard Roles
- Kibana Tenants
Notable changes and improvements at a glance:
- The new format does now allow dots (
.
) in index names and regular expressions - Every file now has mandatory
_sg_meta
header - Structure and wording is now more precise, aligned and extensible
- Additional config file for tenants (
sg_tenants.yml
)
If you do a migration from Elasticsearch/Search Guard 6.x please refer to the upgrade instructions to learn how to migrate the configuration to it’s new format.
If you are using the REST API, you will likely need to change the payload processing of your calls slightly.
For the final release we will also provide a standalone tool to migrate the configuration offline (migrate.sh).
BREAKING: Config format validation
Search Guard 6 and before the configuration syntax check were lenient. This can easily lead to misconfiguration. With Search Guard 7 there is now a strict config syntax validation which rejects invalid syntax as well as configuration parameters which do not exist. The REST API and sgadmin will automatically apply these checks.
But in case you are upgrading from 6.x you have to do this one time manually. Please refer to the upgrade instructions in this case. If you miss this step your cluster can become uninitialized which will result in a downtime.
BREAKING: Default changed for snapshot/restore handling
The default of searchguard.enable_snapshot_restore_privilege
changed from false
to true
(in elasticsearch.yml). This will allow restore operations also for regular users without an admin certificate as long as the snapshot does not contain the global cluster state or the searchguard index. See Enabling snapshot and restore for regular users for more details.
BREAKING: Default changed for permissions evaluation across different roles (multi-rolespan)
Before 7.x-35.0.0-rc1 the default was to grant permissions only, if a single role contained all grants necessary to allow a request.
Since 6.x-22.3 there is the multi_rolespan_enabled
config option in sg_config.yml to override this behaviour. The default now changes from multi_rolespan_enabled: false
to multi_rolespan_enabled: true
. This means that a request will be permitted when the combination of all grants from all roles, the user is assigned to, are sufficient to allow access.
BREAKING: Default changed for XFF (x-forwarded-for) support
The default changed from xff.enabled: true
to xff.enabled: false
(in sg_config.yml)
BREAKING: Remove “audit_utc_timestamp” from auditlog and set audit_format_version to 4
Use @timestamp instead of audit_utc_timestamp
BREAKING: Change the default of “searchguard.audit.config.type” from “auditlog” to null
In case of the default value (null) the default type _doc will be used
BREAKING: Remove “trustedProxies” and “proxiesHeader” config options for Xff because they are unused since SG 6
You can safely remove them from sg_config.yml
BREAKING: Remove “order” config options from authz, it was erroneously added in rc1
You can safely remove them from sg_config.yml (in authz section, NOT authc section!).
BREAKING: Change default auditlog index name to “‘sg7-auditlog-‘YYYY.MM.dd”
If you need the old behaviour set searchguard.audit.config.index: "'sg6-auditlog-'YYYY.MM.dd"
BREAKING: Always return a JSON response for REST Api with correct content-type header
All endpoints now return valid JSON with content-type application/json
DEPRECATION: deprecate “_searchguard/api/sgconfig” in favor of “_searchguard/api/sg_config”
The deprecated API endpoint will be removed in SG 8.
New feature: Built-in configuration resources
Search Guard 7 ships with built-in roles and actiongroups. Those are static and unchangeable and will be maintained from release to release by us. We strongly recommend to use them where ever possible and prefer them over your own roles and actiongroups. Albeit recommended their usage is not mandatory.
All built-in resource are uppercase and start with SGS_
.
New feature: Tenant endpoint for REST management API
For the new tenant file there is now also a corresponding tenant REST API endpoint /_searchguard/api/tenants/
.
Please refer to the documentation for any details.
New feature: New options for sgadmin to support migration and backups
sgadmin now has this additional command line options:
-migrate <folder>
to automatically migrate configuration to the new format when upgrading from 6.x to 7.x., see here for more details-vc <version>
to validate the configuration, see here for more details-backup <folder>
to backup the configuration, see here for more details--migrate-offline <folder>
for offline migration of config files
Fixes
- Change built-in SGS_LOGSTASH role to include cluster pipeline put+get permissions so that logstash and beats can manage their pipelines