Hi,
@sscarduzio
I wanted to ask like if one user create a dashboard then can another user delete the dashboard?
as the dashboards are stored in .kibana index and every user has a rw access on it!
Hi @shubhamverma27,
if all users are set in the same RoR block as kibana_access : rw , then yes, they can delete/overwrite dashboard of others.
also, in Documentation, there is a way to separate specific kibana indice per each user.
see here
@sscarduzio has in mind to work on something to finegrain access in indices in a future release, also in kibana.
I also provided a workaround here
this way keep the same indice, but work on rules and constraints.
you can see the 2 RoR blocks , and a policy definition has to be made regarding naming convention.
In the documentation way … Do I need to do something else too?
as if i use .kibana_@{user} then I get only a blank page …no kibana discover/dashboard etc ?
See The Settings
name: ldaptest2 ldap_authentication: "ldap1" ldap_authorization: name: "ldap1" # ldap name from 'ldaps' section groups: ["xxx"] # group within 'ou=Groups,dc=example,dc=com' kibana_access: rw kibana_index: ".kibana_xxx" indices: [".kibana_xxx", ".kibana-devnull","@{user}_clas",".kibana"] verbosity: info
Its Still accessing the .kibana index not .kibana_xxx
it is normal, you forgot to remove “.kibana” in indice array.
name: ldaptest2
ldap_authentication: "ldap1"
ldap_authorization:
name: "ldap1" # ldap name from 'ldaps' section
groups: ["xxx"] # group within 'ou=Groups,dc=example,dc=com'
kibana_access: rw
kibana_index: ".kibana_xxx"
indices: [".kibana_xxx", ".kibana-devnull","@{user}_clas"]
verbosity: infoAlso, 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
Also got this log
id: 368084983-300989071-sub-1648814113 - Not replacing in sub-request. Indices are the same. Old:[.kibana] New:[.kibana]
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 :
- name: ldaptest2_kibanaSec
ldap_authentication: "ldap1"
ldap_authorization:
name: "ldap1"
groups: ["SECU_team"]
type: allow
methods: [POST,DELETE]
uri_re: ^/.kibana/.*?((?i)VISU_|DASH_|SEAR_)(?i)SECU.*
kibana_access: rw
verbosity: info
- name: ldaptest2_kibanaComm
ldap_authentication: "ldap1"
ldap_authorization:
name: "ldap1"
groups: ["COMM_team"]
type: allow
methods: [POST,DELETE]
uri_re: ^/.kibana/.*?((?i)VISU_|DASH_|SEAR_)(?i)COMM.*
kibana_access: rw
verbosity: info
- name: ldaptest2_Indices
ldap_authentication: "ldap1"
ldap_authorization:
name: "ldap1"
groups: ["SECU_team","COMM_team"]
type: allow
kibana_access: ro
verbosity: info
indices: [".kibana", ".kibana-devnull","@{user}_clas"]
verbosity: info
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
1 Like
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
I found out that giving kibana access as rw does not allow to delete a dashboard…
So I guess that’s better than using this workaround ? 
mmmh it is not a normal behavior…
kibana_access: ro (give access as readonly to all dash/visu/search - cannot delete/update/replace/create)
kibana_access: rw (give access as readwrite to all dash/visu/search - can delete/update/replace/create)
my blocks combinaison works because of the mix of uri_re and methods
could you post your RoR Yml section, to see which rules was hit ?
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
@ld57 I am Very Close to completing it …
So what I did is
added
Kibana_index with indices _rewrite and giving access to both .kibana and .kibana_xxx
kibana_access: rw
kibana_index: “.kibana_xxxx"
indices_rewrite: [”^\.kibana.*", “.kibana_xxx”]
indices: [".kibana", “.kibana-devnull”,"@{user}_clas",".kibana_xxx"]
Now the only Problem left is that if .kibana_xxx does not exist then it does not automatically create it…
How can I define that now?
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)