-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Field aliases implementation tracking #31372
Comments
Pinging @elastic/es-search-aggs |
I put down some initial thoughts around field alias support in other contexts besides search requests + field capabilities. @jpountz I'm curious as to your opinions, and also whether I'm missing any important APIs.
For clearing caches and term vectors, my current thought is that in this initial version we should focus on search requests (and field capabilities), and can wait for feedback as to whether it's valuable to add support for aliases in other APIs. In general, we won't commit to supporting aliases in all APIs where a field name can be supplied, but explicitly focus on search requests (and closely related APIs like field capabilities) where they are critical for certain functionality. |
I don't think we should do this one as I think people using this API should be shown the actual mapping of the field (i.e. the fact its an alias field and what it points to) rather than resolving the alias. This fits with the standard mapping API which also does not resolve the alias for alias fields.
I agree
IMO we should error on alias fields here and require the user to clear the cache explicitly on the concrete field. This API is really for admins to use and they should know the concrete field since clearing the cache is usually something that would be done in response to an issue being debugged
We may have requests for alias support here later down the line but I agree that we don't need to implement this for the first version |
@jtibshirani Agreed with your initial thoughts, I added some comments below.
I read this as "the get field mappings API will work and return the mapping of the alias" rather than resolving the alias, but @colings86 's comment suggests he is reading it the other way around. I think it should not try to resolve the alias indeed. My reasoning is that mappings not only have search-time implications but also index-time implications. If a field is shown as mapped as long, then it would suggest that it is fine to feed it with long values, which is not correct if the field is an alias.
Field capabilities are only about read-only capabilities of fields (on the contrary to mappings) so it makes sense to resolve aliases. This is probably a requirement for Kibana to work transparently with aliases as well.
Agreed with @colings86: this is an admin operation, let's not resolve aliases. |
Thank you @colings86 and @jpountz for the thoughts! I've updated the issue description. To clarify my comment around retrieving field mappings: I indeed meant to say 'the get field mappings API will work and return the mapping of the alias'. I agree that it does not make sense to resolve the alias here, but I think users should be able to see the |
👍 |
We discussed this during this weeks security team meeting. If a user has access to the underlying field then the field alias should also be seen. Given that field level security works at the lucene level, field level security execution will not care about the field aliases or perform any filtering based on a alias. Where things could get messy is how field aliases play with the field filter used in the mapper registry. It would be odd for field level security to be in use and a user can see a field and its alias when getting the document, but they would not be able to see the alias in the mappings api and the other apis that this filter applies to. |
Thanks @jaymode for the update. To summarize my understanding from your comment/ watching the meeting recording:
I'll give some thought as to how to address the last point. It'd be useful to know for context: is the existence of a field considered sensitive information? If not, is its mapping/ schema information sensitive, or is the field mappings filter mostly for better user experience? |
@jtibshirani You're understanding is correct.
The best thing would be to not allow the knowledge of the existence of a field to exist and if that isn't possible not knowing the mapping would be better than nothing. Ultimately we want our FLS implementation to prevent the user from knowing that a given field exists in a document. The field mappings filter is a relatively new thing and prior to that users with access to certain APIs could still find out about fields that they did not have access to, so it is not the end of the world if this is not a problem that can be solved. |
👍 thanks! |
An update on field-level security: I uploaded a PR for consideration (#31807). |
This feature branch was merged into master in #32172. |
Main issue: #23714
Feature branch:
field-aliases
Documentation: https://github.com/elastic/elasticsearch/blob/master/docs/reference/mapping/types/alias.asciidoc
Summary of technical approach:
type: alias
. This mapping has largely the same structure and handling as a standard field mapping. In the code it corresponds to a new top-levelMapper
type calledFieldAliasMapper
, that does not inherit fromFieldMapper
.MapperService
so that when field aliases are supplied toMapperService#fullName
, the correct concreteMappedFieldType
is returned. This concrete field type is then used in creating queries, fetching doc values, etc. This PR attempts to remove other ways of accessing a field'sMappedFieldType
that wouldn't handle aliases, as inDocumentFieldMappers#getMapper
.TODO:
stored_fields
. Allow for aliases when fetching stored fields. #31411_source
or invalidating the indices cache for a field). Add documentation around field aliases. #31538DocumentFieldMappers#getFieldMapper
. Remove the deprecated method DocumentFieldMappers#getFieldMapper. #32148The text was updated successfully, but these errors were encountered: