Hi guys, Just wanted to ask what do you think about this humble beginning 
Look at the bottom left corner…
Good one! 
Is this also a kibana plugin or you manage to send that via elasticsearch?
Via elasticsearch? In my dreams… This is had to be a kibana plugin 
.
But you know, having a foot in the door in Kibana as a platform could be a good start for some cool features
via elasticsearch would only work if you were reusing some API (if it exists) set for the elastic x-pack
but yes, a kibana plugin open the door to several other features, like managing users, restrict access to dashboards and others 
@danielmotaleite I thought about reimplementing the ES side of xpack, but then two things:
- I’d be flying too close to the copyright issues
- I’d be soooo dependent on every little change they make, it’s enough to keep the pace with ES internal API.
- Precludes the freedom of differentiation: I can’t really innovate in different directions other than what xpack product manager decides.
Nice approach ! I like the idea of integrating in kibana the management too.
@sscarduzio @danielmotaleite Yes user management will need to be a Kibana plugin in the end. Might as well start with the logout.
Wouldn’t User Management as a Kibana Plugin mean that the config would now need to reside in a Index that was Public?
The configuration index will always be inaccessible, you’ll only be able to write and read to it through a REST API implemented within the ES plugin itself.
There’s no need for the configuration to be read by Kibana or browsers. Unless they need to edit it, but then the
API will require the REST request to carry admin credentials.
More sneak peaks!
Hi guys, I’ve been busy these last 3 days on trying to make something out of this Kibana companion plugin. I hope you like what’s there! 
1. You can forbid user to access some Kibana apps!
Example configuration:
readonlyrest:
enable: true
access_control_rules:
- name: Kibana
auth_key: kibana:kibana
type: allow
- name: Browser
kibana_hide_apps: ["timelion","kibana:discover", "kibana:visualize", "kibana:dev_tools", "kibana:management"]
auth_key: rw:dev
type: allow
QUESTION: would it be better to allow people to configure what to show or what to hide?
-
kibana_show_apps: [“kibana:dashboard”] -
kibana_hide_apps: [“timelion”, “readonlyrest_kbn”]
0 voters
2) Edit ES cluster security settings from web editor
Syntax-highlighted editor for in-index configuration: make changes on the fly without restarting the ES cluster.
QUESTION 2 Is the editor a sane choice or should we have all the conf translated to an HTML form?
- Converting YAML to web forms would add value to the product
- The YAML editor is more practical (i.e. copy-paste friendly)
0 voters
LET’S BRAINSTORM!
Is this stuff useful so far or would you have imagined to find something else in the Kibana companion plugin?
What would be really nice to have? 
Till next time,
_Simone
For show/hide apps, IMHO the default should be “deny all”+“permited lists”, so any new installed app will not allowed automatically by accident. The way around, if we install any new plugin or apps, users will be able to access it by default and that may be dangerous.
Of course, the deny all require more work to setup and that may not be that friendly for new users
Maybe a option “kibana_apps_access_rule: (show:hide)” and the “kibana_apps_invert_access_rule: [(apps list)]”
This would allow one to choose the default access rule and the use the other option to allow/deny access to apps, depending of what the default is. This would give both worlds, while keeping mostly the same options.
If you do not like a option that change its meaning, use the kibana_hide_apps/kibana_show_apps, but only allow the one that is the opposite of the default and errors when the other is used, so no one tries to mix both
About the settings, native forms are always more friendly… but always give some way to one push yaml via a curl, so tools like chef, puppet, ansible, salt can push configuration changes without requiring any manual changes. This is very important for people that use configuration management systems!
1 Like
Hey all,
I added a few things:
- Show the logged in user name in the logout button.
- Populate the settings from the local ES node, if in-index settings is not found.
- Reload button (re-read current settings, discard modifications)
Wow amazing!!!
Where can i download it?
Hey @kudo!
This is coming really soon. And it’s going to be an separate, paid-for product. Will notify this thread as soon as I set up the website.
It seems very interesting feature , when can we expect these features. Also any plan for dashboard export and raw data into csv or flat file?
Hey, about the Kibana plugin: I got some compatibility issues with Safari, so it’s a bit delayed because I need to rewrite the logout part (with an actual login form, a bit like Xpack).
Right now I’m working for the 1.15 release of the Elasticsearch plugin which is quite a big release, after that I’ll be back on Kibana and ship that thing ASAP.
BTW, thanks for the feature idea about import/export of Kibana dashboards. I really like it.
Can you please write a post in “New Features Ideas” so we don’t loose track of it?
Just one more quick query , do we have kibana session maintenance capability with this plugin .
Yes it already works with a cookie and it goes away when you click logout
Do we have any solution for double authentication. Not sure why it is asking for username and password twice ?
Any Update on double authentication please ?