I would like to know what is the recommended realm for the elasticsearch security with XPACK in Elasticsearch 5.6.
I have known the file realm but i have no clear if migrate it towards the API User Management. In case to migrate all the user security towards the management API, Is mandatory to have open and enabled the .security index forever, right?
File realm is probably the most difficult to maintain when users come and go, because all files backing the realm should be identical over all cluster nodes. From this angle, native realm is more convenient, because you have an API to update users. File realm is recommended as a backup realm when the cluster data got into a broken state and is hindering authn. There is no drawback here because the .security index has to be open in either case. The .security index holds roles and permissions too.
Usually users are managed externality in a directory service (LDAP or AD). In this case LDAP or AD realms are recommended.
We have currently the file realm in productions cluster, we are planning to migrate it towards the native realm because we see that Elasticsearch recommend it, but It is possible to have both realms working together? We have seen that a lot of priviledges have been removed like /admin/flush, admin/refresh, I can't set this kind of priviledges at the native realms system.
@Javier_Parrondo sorry for the delay. In case you haven't figure it out on your own, I'll try to help:
but It is possible to have both realms working together?
Yes, in fact this is the default. From how-authc-works "The default realm chain contains the native and file realms."
We have seen that a lot of priviledges have been removed like /admin/flush, admin/refresh, I can't set this kind of priviledges at the native realms system.
I think you are mixing up concepts. Roles are comprised of privileges and roles are mapped to users irrespective of the realm that had authenticated them. For more details see the x-pack guide . indices:admin/flush and indices:admin/refresh are indices privileges which have NOT been removed. The manage privilege is required for the user running these acctions.
I know exactly what are you telling me. Which i trate to explain you is that now is not possible to add these indexes privileges one by one instead add the whole manage role. The issue comes when you want to have a user with these indexes privileges but not with the rest of the privileges the manage role have, like create/delete indexes and some else.
It's great to use both realms together, i will take into account for my security configurations.
It is still possible to authorise on individual actions, but we no longer recommend it or document it as it is incredibly fragile and is prone to breaking between minor releases as actions are moved or their behaviours change.
We strongly recommend that you only assign the high-level composite priveleges to your roles.
Yes but it is not very safe to give to an application user privileges like appears inside the manage role. User batchs applications use to make masive writes inside elasticsearch indices and need to do a flush or refresh in order to allow see the document just indexed.
I dont know why elastic has change this privileges, for us use to be very useful.
We haven't change them. You can still authorise based on the action names which is what you were doing in earlier versions of Shield. However for the reasons I mentioned earlier, we discourage this.
You are correct that manage grants a large number of privileges, and you may not wish to grant all of those to your users. I have raised an internal issue to look at offering a privilege with less destructive abilities.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.