Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.
I’m not 100% familiar with the Sentinl internals, but … it is usually not the Kibana server user that issues queries. That would make it impossible to implement RBAC for the logged in users. The Kibana server user is mainly used for maintenance, e.g. the infamous health checks from Kibana to Elasticsearch. That’s why a Kibana user typically needs to sets of permissions: One for managing the .kibana index (reading and writing saved objects like Visualizations), and then permissions for the indices the user is allowed to operate on. But having said that - it’s really up to the plugin developer to use either the internal Kibana server user, or the logged in user.
So why does this use case not work:
“But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users.”
Is it that a user can create watches on an index he/she does not have access to? Or is it the READ access for the indices? If Sentinl uses the Kibana server user to write and execute watches, then why would restricting index access for users fail? But as you see - we would need to understand more of the Sentinl inner workings, so you may have a better chance on the Sentinl forum I guess.
···
On Thursday, June 28, 2018 at 3:10:38 PM UTC+2, Håvard Langdal wrote:
Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.
Hi and thanks for responding.
We are trying to find out what user does the query part, if an user is logged out/token expires that would leave the user unable to query and the point of a watcher is to monitor at all times. This is why we suspect that it is the sg_kibana_server. In the documentation Search Guard Documentation 404 | Security for Elasticsearch | Search Guard you specify that the sg_kibana_server needs read access to all indices we want to create alerts for, which is the primary issue.
Another question would be if we could select the searchguard user role ourselves ? (probably not the right forum)
I guess whether an user could create watchers for an index he/she does not have access too would also rely on how it’s implemented in Sentinl,
fredag 29. juni 2018 10.33.48 UTC+2 skrev Jochen Kressin følgende:
···
I’m not 100% familiar with the Sentinl internals, but … it is usually not the Kibana server user that issues queries. That would make it impossible to implement RBAC for the logged in users. The Kibana server user is mainly used for maintenance, e.g. the infamous health checks from Kibana to Elasticsearch. That’s why a Kibana user typically needs to sets of permissions: One for managing the .kibana index (reading and writing saved objects like Visualizations), and then permissions for the indices the user is allowed to operate on. But having said that - it’s really up to the plugin developer to use either the internal Kibana server user, or the logged in user.
So why does this use case not work:
“But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users.”
Is it that a user can create watches on an index he/she does not have access to? Or is it the READ access for the indices? If Sentinl uses the Kibana server user to write and execute watches, then why would restricting index access for users fail? But as you see - we would need to understand more of the Sentinl inner workings, so you may have a better chance on the Sentinl forum I guess.
On Thursday, June 28, 2018 at 3:10:38 PM UTC+2, Håvard Langdal wrote:
Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.
Yes, Sentinl works similar to X-Pack Monitoring in this respect: You have one user that reads, writes and executes watches. Sentinl uses the Kibana server user for that, because watches need to be executable at all times even if no user is logged in. In X-Pack Monitoring you can define a dedicated user/role for that, but IMHO in Sentinl it’s always the Kibana server user.
···
On Friday, June 29, 2018 at 10:52:35 AM UTC+2, Håvard Langdal wrote:
Hi and thanks for responding.
We are trying to find out what user does the query part, if an user is logged out/token expires that would leave the user unable to query and the point of a watcher is to monitor at all times. This is why we suspect that it is the sg_kibana_server. In the documentation https://docs.search-guard.com/latest/search-guard-sentinl you specify that the sg_kibana_server needs read access to all indices we want to create alerts for, which is the primary issue.
Another question would be if we could select the searchguard user role ourselves ? (probably not the right forum)
I guess whether an user could create watchers for an index he/she does not have access too would also rely on how it’s implemented in Sentinl,
fredag 29. juni 2018 10.33.48 UTC+2 skrev Jochen Kressin følgende:
I’m not 100% familiar with the Sentinl internals, but … it is usually not the Kibana server user that issues queries. That would make it impossible to implement RBAC for the logged in users. The Kibana server user is mainly used for maintenance, e.g. the infamous health checks from Kibana to Elasticsearch. That’s why a Kibana user typically needs to sets of permissions: One for managing the .kibana index (reading and writing saved objects like Visualizations), and then permissions for the indices the user is allowed to operate on. But having said that - it’s really up to the plugin developer to use either the internal Kibana server user, or the logged in user.
So why does this use case not work:
“But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users.”
Is it that a user can create watches on an index he/she does not have access to? Or is it the READ access for the indices? If Sentinl uses the Kibana server user to write and execute watches, then why would restricting index access for users fail? But as you see - we would need to understand more of the Sentinl inner workings, so you may have a better chance on the Sentinl forum I guess.
On Thursday, June 28, 2018 at 3:10:38 PM UTC+2, Håvard Langdal wrote:
Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.
Alright, thanks for clarifying!
I’ll consider looking into it with the others at Sentinl.
fredag 29. juni 2018 11.28.48 UTC+2 skrev Jochen Kressin følgende:
···
Yes, Sentinl works similar to X-Pack Monitoring in this respect: You have one user that reads, writes and executes watches. Sentinl uses the Kibana server user for that, because watches need to be executable at all times even if no user is logged in. In X-Pack Monitoring you can define a dedicated user/role for that, but IMHO in Sentinl it’s always the Kibana server user.
On Friday, June 29, 2018 at 10:52:35 AM UTC+2, Håvard Langdal wrote:
Hi and thanks for responding.
We are trying to find out what user does the query part, if an user is logged out/token expires that would leave the user unable to query and the point of a watcher is to monitor at all times. This is why we suspect that it is the sg_kibana_server. In the documentation https://docs.search-guard.com/latest/search-guard-sentinl you specify that the sg_kibana_server needs read access to all indices we want to create alerts for, which is the primary issue.
Another question would be if we could select the searchguard user role ourselves ? (probably not the right forum)
I guess whether an user could create watchers for an index he/she does not have access too would also rely on how it’s implemented in Sentinl,
fredag 29. juni 2018 10.33.48 UTC+2 skrev Jochen Kressin følgende:
I’m not 100% familiar with the Sentinl internals, but … it is usually not the Kibana server user that issues queries. That would make it impossible to implement RBAC for the logged in users. The Kibana server user is mainly used for maintenance, e.g. the infamous health checks from Kibana to Elasticsearch. That’s why a Kibana user typically needs to sets of permissions: One for managing the .kibana index (reading and writing saved objects like Visualizations), and then permissions for the indices the user is allowed to operate on. But having said that - it’s really up to the plugin developer to use either the internal Kibana server user, or the logged in user.
So why does this use case not work:
“But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users.”
Is it that a user can create watches on an index he/she does not have access to? Or is it the READ access for the indices? If Sentinl uses the Kibana server user to write and execute watches, then why would restricting index access for users fail? But as you see - we would need to understand more of the Sentinl inner workings, so you may have a better chance on the Sentinl forum I guess.
On Thursday, June 28, 2018 at 3:10:38 PM UTC+2, Håvard Langdal wrote:
Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.
Another question would be how the Kibana server user acutally executes the watchers? Would it get them from the global .kibana index or users private .kibana index or some predefined index for all the watchers?
fredag 29. juni 2018 11.28.48 UTC+2 skrev Jochen Kressin følgende:
···
Yes, Sentinl works similar to X-Pack Monitoring in this respect: You have one user that reads, writes and executes watches. Sentinl uses the Kibana server user for that, because watches need to be executable at all times even if no user is logged in. In X-Pack Monitoring you can define a dedicated user/role for that, but IMHO in Sentinl it’s always the Kibana server user.
On Friday, June 29, 2018 at 10:52:35 AM UTC+2, Håvard Langdal wrote:
Hi and thanks for responding.
We are trying to find out what user does the query part, if an user is logged out/token expires that would leave the user unable to query and the point of a watcher is to monitor at all times. This is why we suspect that it is the sg_kibana_server. In the documentation https://docs.search-guard.com/latest/search-guard-sentinl you specify that the sg_kibana_server needs read access to all indices we want to create alerts for, which is the primary issue.
Another question would be if we could select the searchguard user role ourselves ? (probably not the right forum)
I guess whether an user could create watchers for an index he/she does not have access too would also rely on how it’s implemented in Sentinl,
fredag 29. juni 2018 10.33.48 UTC+2 skrev Jochen Kressin følgende:
I’m not 100% familiar with the Sentinl internals, but … it is usually not the Kibana server user that issues queries. That would make it impossible to implement RBAC for the logged in users. The Kibana server user is mainly used for maintenance, e.g. the infamous health checks from Kibana to Elasticsearch. That’s why a Kibana user typically needs to sets of permissions: One for managing the .kibana index (reading and writing saved objects like Visualizations), and then permissions for the indices the user is allowed to operate on. But having said that - it’s really up to the plugin developer to use either the internal Kibana server user, or the logged in user.
So why does this use case not work:
“But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users.”
Is it that a user can create watches on an index he/she does not have access to? Or is it the READ access for the indices? If Sentinl uses the Kibana server user to write and execute watches, then why would restricting index access for users fail? But as you see - we would need to understand more of the Sentinl inner workings, so you may have a better chance on the Sentinl forum I guess.
On Thursday, June 28, 2018 at 3:10:38 PM UTC+2, Håvard Langdal wrote:
Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.
Also this is an implementation detail of Sentinl, but I would guess they store it in a central index, but probably not the .kibana index.
···
On Friday, June 29, 2018 at 2:56:42 PM UTC+2, Håvard Langdal wrote:
Another question would be how the Kibana server user acutally executes the watchers? Would it get them from the global .kibana index or users private .kibana index or some predefined index for all the watchers?
fredag 29. juni 2018 11.28.48 UTC+2 skrev Jochen Kressin følgende:
Yes, Sentinl works similar to X-Pack Monitoring in this respect: You have one user that reads, writes and executes watches. Sentinl uses the Kibana server user for that, because watches need to be executable at all times even if no user is logged in. In X-Pack Monitoring you can define a dedicated user/role for that, but IMHO in Sentinl it’s always the Kibana server user.
On Friday, June 29, 2018 at 10:52:35 AM UTC+2, Håvard Langdal wrote:
Hi and thanks for responding.
We are trying to find out what user does the query part, if an user is logged out/token expires that would leave the user unable to query and the point of a watcher is to monitor at all times. This is why we suspect that it is the sg_kibana_server. In the documentation https://docs.search-guard.com/latest/search-guard-sentinl you specify that the sg_kibana_server needs read access to all indices we want to create alerts for, which is the primary issue.
Another question would be if we could select the searchguard user role ourselves ? (probably not the right forum)
I guess whether an user could create watchers for an index he/she does not have access too would also rely on how it’s implemented in Sentinl,
fredag 29. juni 2018 10.33.48 UTC+2 skrev Jochen Kressin følgende:
I’m not 100% familiar with the Sentinl internals, but … it is usually not the Kibana server user that issues queries. That would make it impossible to implement RBAC for the logged in users. The Kibana server user is mainly used for maintenance, e.g. the infamous health checks from Kibana to Elasticsearch. That’s why a Kibana user typically needs to sets of permissions: One for managing the .kibana index (reading and writing saved objects like Visualizations), and then permissions for the indices the user is allowed to operate on. But having said that - it’s really up to the plugin developer to use either the internal Kibana server user, or the logged in user.
So why does this use case not work:
“But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users.”
Is it that a user can create watches on an index he/she does not have access to? Or is it the READ access for the indices? If Sentinl uses the Kibana server user to write and execute watches, then why would restricting index access for users fail? But as you see - we would need to understand more of the Sentinl inner workings, so you may have a better chance on the Sentinl forum I guess.
On Thursday, June 28, 2018 at 3:10:38 PM UTC+2, Håvard Langdal wrote:
Apologize if this is the wrong forum to ask, but I’m confident that this may apply to others as well.
This topic involves questions around the watcher plugin Sentinl.
- Search Guard and Elasticsearch version
ES: 6.2.4
SG: 6.2.4-22.3
Sentinl: 6.2.4
I assume that when the user is not logged in, or in general it’s the sg_kibana_server user that queries for each respective user?
Is there are any alternatives to letting sg_kibana_server access all indices that Sentinl is to create alerts for ?
Our use case is to let end users create watchers on indices which they have access too. But letting the scheduler and watcher management run on the Kibana side as the sg_kibana_server creates issues in terms of trying to restrict read access to the different indices by different users. (given that sg_kibana_server does all the work for them) (sg_kibana_server is a highway to all the data (?))
A thought was to let the Sentinl scheduler run as a backend where it’s given the same required permissions, but it’s restricted by hostname.