I work as a developer and deployed community version of Elasticsearch v6.2.4 and Kibana v6.2.4.
Now I have created few Dashboards and the work fine.
Upon discussion with my team they want to know if we can have some sort of authentication to who can see tha dashboards. Meaning only 1 or multiple user can change indexes dashboards in kibana whereas only few created Users can just have READ only access o the dashboards.
I read that we can use Search Guard community version for this purpose since this feature is available in it.
But I feel the sgconfig slightly tough to understand and I can use GUI only for trial version.
Can I create users and roles in GUI while in my trial version and then add below in my ES config.
Will the roles and user still exist afterwards?
searchguard.enterprise_modules_enabled: false
While we are at it, Can someone also tell if I can configure if a particular user can only have access to particular Dashboard.
For Example in below scenarios:-
User 1 - Can read only Dashboard 1.
User 2 - Can Read/Write only Dashboard 2 and Read only Dashboard 1
User 3 - Permission to upload data and create new index
Tons of thanks for any answer provided. If we move forward to establishing ES after the PoC, would definitely recommend Enterprise version of Search Guard to higher management.
The use case you are describing is implemented by the SG Multi Tenancy feature in Kibana, which is not included in the community edition unfortunately. With the multi tenancy you can define tenants, give them read/write or read-only permissions, and assign them to SG roles. A tenant is basically a container for saved objects, like dashboards and visualizations, and separates these objects from objects stored in other tenants.
A typical customer use case would be to define tenants per department. So you can have a “finance” tenant which contains dashboards regarding company financials, an “IT” tenant which contains log analytics dashboards and so on.
We do not offer access control down to the individual dashboard or visualization level. We have it in the backlog, but since we do not get many requests for it, it has rather low priority.
The next feature regarding Kibana is role-based access control to all the different Kibana apps. So you can define that a role is able to see and use the “Dashboards” app, but for example not the “Management” or “Timelion” app. This will be released in the next couple of weeks and will be a Community feature.
Regarding the config GUI: Yes, all SG configuration resides in the Search Guard configuration index on your Elasticsearch cluster. It does not matter if you used sgadmin, the REST API or the config GUI. So even if your trial license has expired, or if you disable the enterprise features, your configuration is untouched.
We are happy to issue a trial license extensions in case you need more time to setup a PoC or to test the SG features. Simply drop us an email to info@search-guard.com and we will take care of it!
Thank you @jkressin for your answer. Much things are clear now.
I got that a tenant can have dashboards/viz saved as objects so only people belonging to that tenant group can access it.
But you also mentioned that you do not offer access control down to individual dashboard and its in the backlog. How different is this from tenant feature which provide limited access of dashboard/viz.
Maybe a good way to look at tenants is to treat them as named containers or buckets for saved objects. Where saved objects (a “Kibana terminology”) include things like dashboards and visualizations, but also index patterns and saved searches.
Whenever a user selects a tenant, all objects she/he saved will be stored in this container/tenant. You can assign access permissions to each container/tenant per Search Guard role.
So you define that a user has read-only permissions for all saved objects in the tenant “Management”, but read/write permissions for all saved objects in the “IT” tenant.
The access permissions however apply to all objects in the tenant. What you cannot do is to define that a user has read-only access to Dashboard A, but read/write access to Dashboard B in the same tenant.