Now, i don’t think we actually need the own home plugin now … as I solved it without it @ld57 
Just One step left of creating rewritten index if its not already there
Also,
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.
Glad you are reaching your goals 
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 
[2017-07-06T13:18:38,606][ERROR][o.e.p.r.e.a.ACLActionListener] indices_rewrite errored handling failure: java.lang.IllegalArgumentException: exception headers must not start with [es.], found [es.resource.id] instead
[.kibana] IndexNotFoundException[no such index]; nested: IllegalStateException[index uuid doesn’t match expected: [_Finb7FoS0uP-dNxQGnmxw] but got: [qVXU19uASiWTFpuH6FFoJA]];
mmh go to my workaround :
1st : copy .kibana indice to .kibana_xxxx
2nd : fix access like
kibana_access: rw
kibana_index: “.kibana_xxxx”
indices: [“.kibana-devnull”,“@{user}clas”,“.kibana_xxx”]
Test and tell me
If I remove .kibana index from indices then i get "YOU CAN"T DO THAT " error on ui and no kibana is displayed for that user
ah sh** I forgot kibana service use the index …
rahhh … the solution I gave to you, works if you use multiple instance of kibana…
tell me, would it be possible and acceptable on your side, to mount a second kibana instance ?
I mean : duplicate the kibana folder to kibana_xxx, edit the config/kibana.yml of the new folder, change the line
kibana.index: ".kibana" to kibana.index: ".kibana_xxx"
change line
server.port: 5601 to server.port: 5603
start this new kinana_xxx instance ( now you have kibana listening on 5601 and kibana_xxx listening on 5603)
give the address to xx.xx.xx.xx:5601 to those users you authorize to kibana indice, and xx.xx.xx.xx:5603 to users you authorize to kibana_xxx
RoR rule blocks, if configured as said, will prevent each users to walk on each other…
Sorry, I forgot this part of details…
This , will completely segregate kibana config between users group
Else, it left my original workaround with naming convention , that I tested.
It may exists some other method, but I did not test on my side yet.
This would actually make everything more complex 
(Creating More than 1 services for kibana etc)… I shall try it .
++ Multi tenancy still a work in progress then we should assume 
@ld57 I did all that and now am running one kibana instance for each group.
Now, One small bug that if one user authenticates through ldap and his kibana index is .kibana_xyz at 5602 port
but he logs onto 5601 with .kibana_abc index (Not in his access)
He gets logged in and is shown a blank page…
Can I set it up to show unauthorized on that kibana instance?
mmmh
do you have your ReadonlyRest yml section starting like
readonlyrest:
enable: true
response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin
and also, could you add this dummy RoR block and retry ?
- name: Dummy (to permit request for basic authentication popup)
auth_key: dummy:dummy
type: forbid
last but not least, is it possible for you to post the RoR blocks ? to see indices
Yes I do,
and I have disabled basic authetication popup
readonlyrest:
enable: true
prompt_for_basic_auth: false
response_if_req_forbidden: Forbidden by Admin
x_forwarded_for: [“0.0.0.0/0”]
access_control_rules:
-
name: "::ADMIN::"
auth_key: admin:devKIBANA ADMIN ACCESS NEEDED TO EDIT SECURITY SETTINGS IN ROR KIBANA APP!
kibana_access: admin
#verbosity: info -
name: “::shub::“
auth_key: shub:dev
type: allow
kibana_access: rw
indices: [”.kibana-devnull”,“testlive”,“clas”,".kibana"]
kibana_hide_apps: [“readonlyrest_kbn”,“sentinl”, “timelion”, “kibana:dev_tools”]
verbosity: info -
name: “::xxx::“
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}_cxxx”]
verbosity: info
Now like these users are there …both are able to login to both 5601 and 5602 even though kibana indices are different @ld57
I see now,
yeah, users are authenticated, then they have access to kibana.
then they are not authorized to see indice, and then they get white page.
mmmh…mhhhhhmmm…mmhhhh well…
@sscarduzio , would it be logic and possible to implement in next release a fine-grained ldap approbation, like :
ldap authentication + ldap authorization , both must match as true to be able to login, else reject the entire RoR block ?
1 Like
@ld57 Just another query …
Like I have a tab of sentinl in my kibana and I want to Deny its access to everyone except the admin…
How to do that…
Like If I hide the tab through readonly … One can still access it if he has the url for it 
I want to hide it + forbid it
(PS: want to forbid only the http://localhost/app/sentinl#/?_g=() page not any index)
RoR is running at level of elasticsearch. but sentinl is running at kibana level.
RoR prevent access to indices, following your previous posted config.
Are users able to see alarm set etc, if they manually use real url of sentinl ? (normally they should get denied access , or prompted to login, since they are not authorized to see the indices watcher and watcher_alarms.)
(@sscarduzio also I have in mind this is rule to be at kibana level, and I think not yet implemented)
Also @shubhamverma27 , it may be more complex, since sentinl is also hiding is presence in Discover tab, under graph (this is their new feature, Gui capture for alarm)
Honestly, as said I did not work yet on sentinl, still in pipe, but I am late in my plan 
@ld57 users are able to set alarm as I had mentioned POST AND GET exceptions for ^/watcher* and ^/watcher-alarms* indices for localhost as Sentinl does not use authetication and Hence has to be forced to be compatible with ror…
Hence, Users through kibana which ultimately are on localhost can access the same too
also, Is there any way to prevent deletion of visualization etc and just allow read and write acces?
If you use my workaround with uri_re and methods and naming convention, you can configure methods to accept only POST and GET.
it should work.