Bug 1710868 - Access to the ES root url / from a project's pod on Openshift 3.11 [NEEDINFO]
Summary: Access to the ES root url / from a project's pod on Openshift 3.11
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Logging
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.11.z
Assignee: Jeff Cantrill
QA Contact: Anping Li
Depends On:
Blocks: 1722959 1724341
TreeView+ depends on / blocked
Reported: 2019-05-16 12:52 UTC by hgomes
Modified: 2019-07-23 19:56 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The permissions between 3.10(es2.x) and 3.11(es5.x) were locked down so that non-admin users were unable to access the root endpoints Consequence: Non-admin users are unable to determine the es version by accessing the root endpoint Fix: Add permissions so everyone is able to see the es version Result: Access to the root endpoint is the same as from prior releases.
Clone Of:
: 1722959 (view as bug list)
Last Closed: 2019-07-23 19:56:23 UTC
Target Upstream Version:
jcantril: needinfo? (hgomes)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift origin-aggregated-logging issues 1641 0 None closed Access to the ES root url / from a project's pod on Openshift 3.11 2021-02-06 00:36:28 UTC
Github openshift origin-aggregated-logging pull 1674 0 None closed Bug 1710868: Allow access to reading root es endpoint 2021-02-06 00:36:28 UTC
Red Hat Product Errata RHBA-2019:1753 0 None None None 2019-07-23 19:56:35 UTC

Description hgomes 2019-05-16 12:52:22 UTC
When implemented an instance of "elastalert" (https://github.com/Yelp/elastalert) that uses a service account to access the elasticsearch backend.

After the upgrade from 3.10 to 3.11 the Elastalert refuses to start because it cannot longer access the root URL of the elasticsearch cluster ("/")
Error message is somethin like:

  {"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [cluster:monitor/main]     and User [name=system:serviceaccount:dbms-preprod:elastalert, roles=[gen_kibana_b08432e716e206e07b426a7d344ea27b9bc7f96e, gen_user_b08432e716e206e07b426a7d344ea27b9bc7f96e]]"}],"type":"security_exception","reason":"no permissions for [cluster:monitor/main] and User [name=system:serviceaccount:dbms-preprod:elastalert, roles=[gen_kibana_b08432e716e206e07b426a7d344ea27b9bc7f96e, gen_user_b08432e716e206e07b426a7d344ea27b9bc7f96e]]"},

All other Endpoints and searching the user's project indices still works as expected.
Elastalert uses the "/" endpoint to check the elasticsearch version, but if that fails it refuses to start.

There is already a Openshift Origin issue for that.

Was managed to workaround this by adding a static "/" info page to the auth-proxy.

But as this behavior looks like a regression introduced in 3.11 a proper fix seems suitable.

Comment 1 Rich Megginson 2019-05-16 13:19:14 UTC
(In reply to hgomes from comment #0)
> But as this behavior looks like a regression introduced in 3.11 a proper fix
> seems suitable.

Correction - it was technically not a regression - it was only an "accident" that the root "/" URL was readable in 3.10 and earlier.  It was not part of the public API.  The supported OpenShift logging EFK stack does not require permission to view "/".

I'm not saying we won't fix it, but be careful about the use of the term "regression", and technically this is an RFE, not a bug.

Comment 3 Jeff Cantrill 2019-06-21 15:57:06 UTC
Are you able to tell me what role this SA had in 3.10 "system:serviceaccount:dbms-preprod:elastalert"?  Looking at 3.10 action groups [1] and our declared permissions [2], there are none which match "cluster:monitor/main" unless the user/SA is in a role that can answer 'oc -n default auth can-i view pods/logs' [3] which would give them admin rights for ES.  The alternative reasoning:

* Maybe this endpoint was not guarded in 2.x
* User manually adjusted the permissions for it to be open

[1] https://github.com/openshift/origin-aggregated-logging/blob/release-3.10/elasticsearch/sgconfig/sg_action_groups.yml
[2] https://github.com/fabric8io/openshift-elasticsearch-plugin/blob/2.4.4/src/test/resources/io/fabric8/elasticsearch/plugin/user_role_with_shared_kibana_index_with_unique.yml#L13
[3] https://github.com/openshift/origin-aggregated-logging/blob/master/docs/access-control.md

Comment 4 Jeff Cantrill 2019-06-21 16:01:08 UTC
In support of one of my theories I don't see the failed permission listed in the original values available [1] which makes me think it was originally unguarded

[1] https://www.elastic.co/guide/en/shield/2.2/privileges-list.html#ref-actions-list

Comment 6 Anping Li 2019-07-11 10:46:34 UTC
Pass when using openshift3/ose-logging-elasticsearch5:v3.11.128

Comment 8 errata-xmlrpc 2019-07-23 19:56:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.