Types removal security index template#39705
Conversation
As we are moving to single type indices, we need to address this change in security-related indexes. To address this, we are - updating index templates to use preferred type name `_doc` - updating the API calls to use preferred type name `_doc` Upgrade impact:- In case of an upgrade from 6.x, the security index has type `doc` and this will keep working as there is a single type and `_doc` works as an alias to an existing type. The change is handled in the `SecurityIndexManager` when we load mappings and settings from the template. Previously, we used to do a `PutIndexTemplateRequest` with the mapping source JSON with the type name. This has been modified to remove the type name from the source. So in the case of an upgrade, the `doc` type is updated whereas for fresh installs `_doc` is updated. This happens as backend handles `_doc` as an alias to the existing type name. An optional step is to `reindex` security index and update the type to `_doc`. Since we do not support the security audit log index, that template has been deleted. Relates: elastic#38637
|
Pinging @elastic/es-security |
tvernum
left a comment
There was a problem hiding this comment.
Looks good, but I think my sample parsing code needs to be productionised a bit more with clearer failure cases.
| } | ||
| } | ||
| } | ||
| throw new ElasticsearchException("cannot read mapping from security template"); |
There was a problem hiding this comment.
I recognise that this was pulled from my sample code, but I think we ought to provide more details in this error.
At the very least, what is the currentToken and location that caused a problem.
Alternatively we could switch those nextToken calls to use XContentParserUtils.ensureExpectedToken instead which will handle the exception for us.
There was a problem hiding this comment.
Yes, I have updated this to use ensureExpectedToken and ensureFieldName. Thank you.
| DeprecationHandler.THROW_UNSUPPORTED_OPERATION, mappingSource)) { | ||
| // remove the type wrapping to get the mapping | ||
| if (parser.nextToken() == XContentParser.Token.START_OBJECT) { // { | ||
| if (parser.nextToken() == XContentParser.Token.FIELD_NAME) { // "_doc" |
There was a problem hiding this comment.
We probably want a check (maybe just an assert) on the field name
There was a problem hiding this comment.
changed this to use ensureFieldName checks for the expected field (_doc). Thank you
As we are moving to single type indices, we need to address this change in security-related indexes. To address this, we are - updating index templates to use preferred type name `_doc` - updating the API calls to use preferred type name `_doc` Upgrade impact:- In case of an upgrade from 6.x, the security index has type `doc` and this will keep working as there is a single type and `_doc` works as an alias to an existing type. The change is handled in the `SecurityIndexManager` when we load mappings and settings from the template. Previously, we used to do a `PutIndexTemplateRequest` with the mapping source JSON with the type name. This has been modified to remove the type name from the source. So in the case of an upgrade, the `doc` type is updated whereas for fresh installs `_doc` is updated. This happens as backend handles `_doc` as an alias to the existing type name. An optional step is to `reindex` security index and update the type to `_doc`. Since we do not support the security audit log index, that template has been deleted. Relates: elastic#38637
As we are moving to single type indices, we need to address this change in security-related indexes. To address this, we are - updating index templates to use preferred type name `_doc` - updating the API calls to use preferred type name `_doc` Upgrade impact:- In case of an upgrade from 6.x, the security index has type `doc` and this will keep working as there is a single type and `_doc` works as an alias to an existing type. The change is handled in the `SecurityIndexManager` when we load mappings and settings from the template. Previously, we used to do a `PutIndexTemplateRequest` with the mapping source JSON with the type name. This has been modified to remove the type name from the source. So in the case of an upgrade, the `doc` type is updated whereas for fresh installs `_doc` is updated. This happens as backend handles `_doc` as an alias to the existing type name. An optional step is to `reindex` security index and update the type to `_doc`. Since we do not support the security audit log index, that template has been deleted. Relates: elastic#38637
As we are moving to single type indices, we need to address this change in security-related indexes. To address this, we are - updating index templates to use preferred type name `_doc` - updating the API calls to use preferred type name `_doc` Upgrade impact:- In case of an upgrade from 6.x, the security index has type `doc` and this will keep working as there is a single type and `_doc` works as an alias to an existing type. The change is handled in the `SecurityIndexManager` when we load mappings and settings from the template. Previously, we used to do a `PutIndexTemplateRequest` with the mapping source JSON with the type name. This has been modified to remove the type name from the source. So in the case of an upgrade, the `doc` type is updated whereas for fresh installs `_doc` is updated. This happens as backend handles `_doc` as an alias to the existing type name. An optional step is to `reindex` security index and update the type to `_doc`. Since we do not support the security audit log index, that template has been deleted. Relates: #38637
As we are moving to single type indices, we need to address this change in security-related indexes. To address this, we are - updating index templates to use preferred type name `_doc` - updating the API calls to use preferred type name `_doc` Upgrade impact:- In case of an upgrade from 6.x, the security index has type `doc` and this will keep working as there is a single type and `_doc` works as an alias to an existing type. The change is handled in the `SecurityIndexManager` when we load mappings and settings from the template. Previously, we used to do a `PutIndexTemplateRequest` with the mapping source JSON with the type name. This has been modified to remove the type name from the source. So in the case of an upgrade, the `doc` type is updated whereas for fresh installs `_doc` is updated. This happens as backend handles `_doc` as an alias to the existing type name. An optional step is to `reindex` security index and update the type to `_doc`. Since we do not support the security audit log index, that template has been deleted. Relates: #38637
As we are moving to single type indices,
we need to address this change in security-related indexes.
To address this, we are
_doc_docUpgrade impact:-
In case of an upgrade from 6.x, the security index has type
docand this will keep working as there is a single type and_docworks as an alias to an existing type. The change is handled in the
SecurityIndexManagerwhen we load mappings and settings fromthe template. Previously, we used to do a
PutIndexTemplateRequestwith the mapping source JSON with the type name. This has been
modified to remove the type name from the source.
So in the case of an upgrade, the
doctype is updatedwhereas for fresh installs
_docis updated. This happens asbackend handles
_docas an alias to the existing type name.An optional step is to
reindexsecurity index and update thetype to
_doc.Since we do not support the security audit log index,
that template has been deleted.
Relates: #38637