I am hoping to expose the Kibana dashboard for specific user accounts, extending Kibana and offering more options, templated queries, etc., where the logged in user would not be able to access any other users' data.
How can this be accomplished?
2 Likes
Hi @baden0x1,
The integration with X-Pack Security only allows for restricting access to the data being displayed in the searches, visualizations and dashboards. Applying security restrictions to the search/visualization/dashboard definitions themselves is on the roadmap.
Is it possible to have some of these views only accessible through some other user management system or create parameterized views/reports where we can send in parameters through a REST request?
This way we could create our own dashboard with some of the Kibana bells and whistles.
1 Like
Parameterized/templated dashboards are not explicitly supported in Kibana right now, but will be considered as a future improvement. For now I can think of two workarounds:
For one, the current dashboard state is encoded in the URL, which means you should be able to generate dashboards on-the-fly by generating the appropriate URLs and link to them from some other HTML page or embed them using an iframe. For the serialization format of the state in the URL take a look at https://github.com/jonasfj/rison.
Another option would be to write a separate tool that generates and manipulates the documents of the saved dashboards directly in the .kibana index in Elasticsearch.
My over-all goal is to create a platform where clients will login and only have access to their own data. Since Kibana requests are RESTful, how can we ensure that Client A only accesses their own data?
For example, we can include a ClientID as part of the request (GUID), but that can be hacked. However, the controller that receives client requests can programatically add the ClientID after the request has been received, issue that to to the server and return the appropriate client-specific data.
Is this a strategy that has been used by you guys (I used this in v1 of our platform) - non-ELK.
An additional level of security for something like this is to secure an index based on a client ID. is this possible?
2 Likes
As far as the data are concerned, that can be displayed in Kibana, X-Pack Security enables very fine-grained role-based access control down to the field level (see the documentation for details). So creating user with different data access priviliges in Kibana is supported.
This security model does not yet cover the objects (e.g. saved searches, visualization definitions, dashboard definitions) managed by Kibana itself though. Every user is able to see and change all the searches, visualizations and dashboards even though they might be empty because she is not permitted to perform the associated queries. This is something that is being worked on. For now, many customers use multiple Kibana instances backed by the same Elasticsearch cluster to separate their tenants by configuring each instance to use a different index to store the Kibana settings (kibana.index in kibana.yml). This way the dashboards and searches for each tenant are completely isolated.
So in summary: Yes, X-Pack allows for very fine-grained per-request authorization in Elasticsearch, but Kibana's settings are not included in that security model yet.
Ok, so that I am understanding this correctly, each user account will have a separate Kibana instance on the same ES cluster.
So when new users are created in the system. Is it possible to use automation to create new Kibana instances, and if so, how?
Right - user accounts that share a set of dashboards and visualizations can share a Kibana instance. I would absolutely recommend setting up automation for all services in your infrastructure. A simple way to do this would be to start multiple containers using the official Docker image and to set different KIBANA_INDEX and SERVER_NAME environment variables for each. If you require more customization of the individual instances than can be achieved through setting environment variables, you can just bind-mount different auto-generated kibana.yml files into the containers.
As for automating the creation of visualization and dashboards for each of the aforementioned Kibana instances, the fact that those are stored as documents in the configured Kibana index makes it easy to pre-populate indices using Elasticsearch's http api.
This brings in another question about access to the ES cluster.
In the application abstraction layer, I was thinking of just creating an ES user ID that the back-end code would access. All requests would go through this (using NEST, so having a .Net-written dashboard interface).
Given this type of architecture would it still be possible to serve up user-based Kibana dashbaords?
Regarding using Docker (all new to me):
- All users would be contained within a Users index
- Each user would have their own index, using the _users.metadata hash to identify each document - or would this even be necessary, unless an index had combined user-related data, correct?
- Use index-level security
You can use the native authentication realm to store your user accounts and roles, which would make it possible to manage them via the X-Pack management UI in Kibana.
What you describe in your .Net back-end architecture is exactly what Kibana does. It uses a single Elasticseach account (elasticsearch.username and elasticsearch.password) to access the .kibana index (or whatever index was configured in kibana.index). All search requests for actual data displayed in the dashboards is performed by the browser using the credentials that the user has provided when logging in. That is why all users in a Kibana instance share all dashboards but might see different content on these dashboards.
Unfortunately, I fail to understand what you are trying to explain in the bullet points.
I'm trying to come up with a data model in ES:
- Where should I store user credentials? A separate Users index?
- The platform will allow users to gather data from a variety of sources and organize them into projects. Thus I was thinking of providing a separate index per user.
- The last point index/document-level security - I will not go with. Looking at the cost of X-Pack it is prohibitive.
Since there will not be direct access ElasticSearch and Kibana (access only through the application layer), I will manage all the communications to/from the ES server - adding on user ID's, etc.
I would say that separating data into multiple indices is a good strategy in general. This is supported by Elasticsearch's ability to target multiple indices in one query using wildcards.
With our Keystone plugin we are doing something similar. The logged in user can see only the OpenStack logs of the projects he belongs to.
In ES every project has the set of its own indices.
The user logs in to OpenStack UI and gets the token from Keystone (OpenStack Identity service). The request with the token is then sent to Kibana. The plugin authorizes the token and filters the indices to show only the ones belonging to the user's projects.
The authentication functionality we implemented is OpenStack specific, but restricting access to indices is a generic approach and it would be great to have such functionality in upstream Kibana.
Also for us X-Pack is not an option.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.