Also, I will put more “clear examples” in the next weeks in the forum, to help users to have a better overall vision, with case studies etc etc on how to configure yml stuff, RoR block and ldaps
Well, I can not tell you about the usage of variable inside the RoR settings, I can not help more further with this part.
also, I would recommand you, if you need to implement in short time (else wait for @sscarduzio is back to give more information.) , to try my workaround, that I use. see here
and set back your indice as .kibana , and use 2 blocks.
of course, all members belonging to the same group will be able to delete/replace vizu/dashboard, since they will match block.
to prevent this, split users by spliting RoR blocks, with different groups
If I like have 2 blocks of users
and both have same .kibana index.
Then would one be able to delete the dashboard of the other user?
UPDATE : I tried and its happening , This is a Flaw as If one user creates his dashboards then any other user would be able to delete it which could be disastrous
in fact no, as you can see in my example, with the block Rule uri_re , aligned with the block indices access , based on matching the naming convention will preventuser to delete created vizu/dash from the others group.
let me write down an example based on that you wrote in this thread, it should help to explain better :
In this case, you have to tell to team SECU to create vizu/dash/search with the naming convention of search/visualisation/dashboard as described in my workaround link
example : visualisation VISU_SECU-myvalue can be created/updated/deleted only by SECU team
if COMM member team want to do something , create/update/delete DASH_COMM-mybeautifuldashboard
So this work around will show the names but not allow then to edit the given dashboards? Cool
Also i tried using kibana_index method again
now it says "You can’t do that"
instead of showing kibana in ui…
I guess its not able to change the .kibana index in the backend due to some reason
Yes , It wasn’t so…What I did was that I wrote kibana_index as something else for a user and gave him rw acccess with both .kibana and .kibana_xxx in his indices.
So , It worked like he was not able to delete it but further he was not able to create his own dashboard too
in fact my workaround purpose is to use , for all user, the same .kibana indice.
As I considere dashboard form are not confidential at all then all users can see kibana forms from others, but can not modify them.
It is not the case for indices content, which are to be secured.
with rules blocks as shown (2 blocks uri_re + indices power), I prefered to define one rule for .kibana rights , and the second one for indices data access.
Yes, I understood your method…But am still trying to implement kibana own_home plugin So that I can Seperate the .kibana indices itself and provide groupwise indices
I looked at this plugin, but not invested time in further yet.
Currently, @sscarduzio is consolidating all code released, to improve visibility for developper.
We currently testing compatibility adaptation of the RoR over all es 2.x and 5.x version of ELK,
and also I am also challenging ldap module.
My next step is to validate sentinl module compatibility adaptation as you requested in a previous post, because this is a great third party tool in which one I will invest time to work on.
kibana own home testing is on my pipe too, but I know @sscarduzio started a reflexion about that.
also, an another way, if you want to completely segregate kibana, you can mount x kibana server instance, with a different port, and also a different indice name like .kibana-1 .kibana-2
In RoR you configure kibana service blocks for each instance, and then , you can specify rights on the good .kibana-x indice in the indice arrays of users dblock definition. ( like you did for .kibana-xxx)
you just need to clone the .kibana indice.
I use on my side Kopf, but I am in es 2.x .
do you use a 3rd parties like head or cerebro ? or else, if you know the rest command, you can clone with new name.
When you ended with success to clone the .kibana indice to .kibana-xxx, I suggest you to remove the .kibana indice from the array of the rule block where your users have not to use it, and let jsut the -xxx one.
Now I am Not able to Create / Delete anything / any index pattern as It Rewrites the .kibana indice but while the next get / post request it again accesses .kibana