Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not sufficient permissions to access license information on remote monitoring cluster #37970

Closed
radoondas opened this issue Jan 29, 2019 · 5 comments
Assignees
Labels

Comments

@radoondas
Copy link
Member

radoondas commented Jan 29, 2019

Elasticsearch version (bin/elasticsearch --version): 6.5.4

Plugins installed: [none]

JVM version (java -version): OpenJDK 64-Bit Server VM 11.0.1

OS version (uname -a if on a Unix-like system): not relevant

Description of the problem including expected versus actual behavior:

When using least privileges for user defined to read monitoring data in remote monitoring cluster, this user is missing some of the permissions to show all information in Monitoring application.

Steps to reproduce:
Production cluster and Monitoring cluster.
Both have valid Gold/Platinum license.
Production cluster is sending data to Remote monitoring cluster.

To allow Production cluster Kibana with Monitoring UI to read monitoring data from remote Monitoring cluster, configuration for least privileges is suggested in the documentation (point 3.)
https://www.elastic.co/guide/en/kibana/current/monitoring-data.html

Correct user is defined in Monitoring cluster and This user is also configured in Production Kibana configuration file according to documentation above.

User definition

"monitor_viewer" : {
    "username" : "monitor_viewer",
    "roles" : [
      "monitoring_user"
    ],
    "full_name" : "Monitor viewer for Kibana",
    "email" : "",
    "metadata" : { },
    "enabled" : true
  }

In Production, we are missing Cluster status due to license issue.
issue

Accessing _xpack endpoint which is required for license check provides following permission error.

curl -k -u monitor_viewer https://<monitoring_hostname>:9200/_xpack/?pretty 
Enter host password for user 'monitor_viewer': 
{ 
 "error" : { 
   "root_cause" : [ 
     { 
       "type" : "security_exception", 
       "reason" : "action [cluster:monitor/xpack/info] is unauthorized for user [monitor_viewer]" 
     } 
   ], 
   "type" : "security_exception", 
   "reason" : "action [cluster:monitor/xpack/info] is unauthorized for user [monitor_viewer]" 
 }, 
 "status" : 403 
}

This means that in Production Kibana Monitoring tab, some of the informations are missing due to limited privileges for the role monitoring_user

I would expect that role monitoring_user have all required permissions.

@javanna javanna added the :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC label Jan 29, 2019
@ycombinator ycombinator self-assigned this Jan 29, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@chrisronline
Copy link
Contributor

From a UI perspective, we're pulling live license information [1] from the monitoring cluster [2] using the logged in user[3]. The necessary call for this information is /_xpack[3] which requires more permissions than monitoring_user grants.

  1. https://github.com/elastic/kibana/blob/master/x-pack/plugins/monitoring/server/init_monitoring_xpack_info.js#L21
  2. https://github.com/elastic/kibana/blob/master/x-pack/plugins/monitoring/server/init_monitoring_xpack_info.js#L16
  3. https://github.com/elastic/kibana/blob/master/x-pack/plugins/xpack_main/server/lib/xpack_info.js#L139

@ycombinator
Copy link
Contributor

@chrisronline Are you sure it's the logged-in user? The function name in [3] seems to suggest that it's an internal user. If it's an internal user, could you verify which internal user this when this code is called by the Monitoring UI code - elasticsearch.username OR xpack.monitoring.elasticsearch.username falling back to elasticsearch.username?

@chrisronline
Copy link
Contributor

Yes, you are correct.

It is the elasticsearch.username

ycombinator added a commit that referenced this issue Feb 1, 2019
This PR adds the `monitor/xpack/info` cluster-level privilege to the built-in `monitoring_user` role.

This privilege is required for the Monitoring UI to call the `GET _xpack API` on the Monitoring Cluster. It needs to do this in order to determine the license of the Monitoring Cluster, which further determines whether Cluster Alerts are shown to the user or not.

Resolves #37970.
ycombinator added a commit to ycombinator/elasticsearch that referenced this issue Feb 1, 2019
…8060)

This PR adds the `monitor/xpack/info` cluster-level privilege to the built-in `monitoring_user` role.

This privilege is required for the Monitoring UI to call the `GET _xpack API` on the Monitoring Cluster. It needs to do this in order to determine the license of the Monitoring Cluster, which further determines whether Cluster Alerts are shown to the user or not.

Resolves elastic#37970.
ycombinator added a commit that referenced this issue Feb 1, 2019
Backport of #38060 to `6.x`. Original description:

This PR adds the `monitor/xpack/info` cluster-level privilege to the built-in `monitoring_user` role.

This privilege is required for the Monitoring UI to call the `GET _xpack API` on the Monitoring Cluster. It needs to do this in order to determine the license of the Monitoring Cluster, which further determines whether Cluster Alerts are shown to the user or not.

Resolves #37970.
ycombinator added a commit to ycombinator/elasticsearch that referenced this issue Feb 1, 2019
…8060)

This PR adds the `monitor/xpack/info` cluster-level privilege to the built-in `monitoring_user` role.

This privilege is required for the Monitoring UI to call the `GET _xpack API` on the Monitoring Cluster. It needs to do this in order to determine the license of the Monitoring Cluster, which further determines whether Cluster Alerts are shown to the user or not.

Resolves elastic#37970.
ycombinator added a commit that referenced this issue Feb 1, 2019
Backport of #38060 to `6.6`. Original description:

This PR adds the `monitor/xpack/info` cluster-level privilege to the built-in `monitoring_user` role.

This privilege is required for the Monitoring UI to call the `GET _xpack API` on the Monitoring Cluster. It needs to do this in order to determine the license of the Monitoring Cluster, which further determines whether Cluster Alerts are shown to the user or not.

Resolves #37970.

<!--
Thank you for your interest in and contributing to Elasticsearch! There
are a few simple things to check before submitting your pull request
that can help with the review process. You should delete these items
from your submission, but they are here to help bring them to your
attention.
-->

- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md)?
- If submitting code, have you built your formula locally prior to submission with `gradle check`?
- If submitting code, is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
- If submitting code, have you checked that your submission is for an [OS that we support](https://www.elastic.co/support/matrix#show_os)?
- If you are submitting this code for a class then read our [policy](https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md#contributing-as-part-of-a-class) for that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants