Bug 1821771 - anonymous browsers should get a 403 from /
Summary: anonymous browsers should get a 403 from /
Keywords:
Status: VERIFIED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 4.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.6.0
Assignee: Andrea Hoffer
QA Contact: scheng
URL:
Whiteboard: LifecycleReset
: 1821954 (view as bug list)
Depends On:
Blocks: 1879650 1878095
TreeView+ depends on / blocked
 
Reported: 2020-04-07 15:08 UTC by Luis Sanchez
Modified: 2020-09-16 17:46 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
In OpenShift release 4.1, an anonymous user could access discovery endpoints. Later releases revoked this access by removing unauthenticated subjects from cluster role bindings. Because of the way default policy resources are reconciled, unauthenticated access is preserved in upgrade clusters. The ability to revoke this access after upgrading a cluster can be added to OpenShift. But, as doing that automatically would break existing use-cases, cluster administrators are given the ability to chose the best path forward based on their use case. There could be up to five cluster role bindings in an OpenShift 4.6 cluster that give unauthenticated user access to discovery endpoints. 1. cluster-status-binding 2. discovery 3. system:basic-user 4. system:discovery 5. system:openshift:discovery Cluster administrators can revoke unauthenticated access by using the below shell script. Please note that after running this snippet, an application that relied on unauthenticated behavior might start to receive HTTP 403 from the API Server. ## Snippet to remove unauthenticated group from all the cluster role bindings. $ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ; do ### Find the index of unauthenticated group in list of subjects index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)'); ### Remove the element at index from subjects array oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]"; done
Clone Of:
: 1822681 1878095 (view as bug list)
Environment:
Last Closed: 2020-08-20 14:28:13 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift openshift-docs pull 25048 None closed Bug 1821771: Adding known issue and workaround with unauthenticated a… 2020-09-21 13:02:47 UTC
Github openshift origin pull 25460 None closed Bug 1821771: For clusters upgraded from 4.1, skip the anonymous browser access test 2020-09-21 13:02:47 UTC
Red Hat Bugzilla 1711533 None None None 2020-04-09 11:45:09 UTC

Description Luis Sanchez 2020-04-07 15:08:33 UTC
Description of problem:

anonymous browser should get a 403 from /, getting 200 instead.


Reproduce:

   curl --insecure https://api..../ 


Additional info:

Happens in 4.1->4.2->4.3->4.4 upgrade.

https://search.svc.ci.openshift.org/?search=anonymous+browsers+should+get+a+403+from&maxAge=48h&context=2&type=bug%2Bjunit

Comment 1 Luis Sanchez 2020-04-07 15:11:09 UTC
Related test failure:

[It] [Top Level] [Feature:OpenShiftAuthorization] The default cluster RBAC policy should have correct RBAC rules [Suite:openshift/conformance/parallel]
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/test/extended/authorization/rbac/groups_default_rules.go:163
STEP: should only allow the system:authenticated group to access certain policy rules
STEP: should only allow the system:unauthenticated group to access certain policy rules
Apr  7 06:36:18.550: FAIL: system:unauthenticated has extra permissions in namespace "":

Comment 2 Standa Laznicka 2020-04-08 11:41:02 UTC
*** Bug 1821954 has been marked as a duplicate of this bug. ***

Comment 4 Stefan Schimanski 2020-04-08 11:50:21 UTC
This is by design of rbac reconciliation, and the switch to authenticated / and discovery endpoints. This is certainly no regression of 4.4 and therefore doubtfully a blocker.

Comment 5 Stefan Schimanski 2020-04-08 11:52:36 UTC
Moving back to 4.5, with backports, and priority high.

Comment 6 Ben Parees 2020-04-13 16:13:19 UTC
Can I get an update on the progress of this bug?  The fix needs to be backported to 4.4 to unblock upgrades.

Comment 7 Venkata Siva Teja Areti 2020-04-13 22:01:31 UTC
In my testing I found that this issue is present in 4.1->4.2 upgrade as well. I put up an PR that could potentially resolve the issue. Will work with Stefan and Standa to refine the PR and merged it.

Comment 8 Venkata Siva Teja Areti 2020-05-20 12:34:28 UTC
this bug is actively worked on.

Comment 9 Venkata Siva Teja Areti 2020-06-18 10:59:41 UTC
I will revisit this after finishing up my current tasks.

Comment 10 Venkata Siva Teja Areti 2020-07-09 19:09:00 UTC
I am planning to resume the work in this sprint.

Comment 11 Venkata Siva Teja Areti 2020-07-31 18:45:41 UTC
I am working on other high priority items. I will get to this bug next sprint.

Comment 12 Michal Fojtik 2020-08-20 11:47:35 UTC
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

Comment 13 Ben Parees 2020-08-20 13:13:09 UTC
this bug had an update from the assignee less than 30 days ago, so the bot shouldn't have taken action. Michal is looking into it.  Setting the priority back for now.

Comment 16 Venkata Siva Teja Areti 2020-08-20 14:28:13 UTC
Closing this issue. Issue as such is not reproduced in CI in the latest runs. Whatever failures present in ci search are due to network or io issues.

Comment 17 Ben Parees 2020-08-20 14:33:23 UTC
pretty sure this isn't showing up because we disabled the test.  Do you have evidence the test has actually passed in recent CI runs?

Comment 18 Ben Parees 2020-08-20 14:36:44 UTC
Not to mention it should be very easy to test the actual behavior to see if it is correct:

anonymous browser should get a 403 from /, getting 200 instead.



is it?

Comment 19 Ben Parees 2020-08-20 14:37:41 UTC
(the behavior only happens when you start from a 4.1 cluster and upgrade through to 4.5 or so, i don't think it happens if you just install a 4.5 cluster fresh)

Comment 20 Michal Fojtik 2020-08-24 08:32:41 UTC
The LifecycleStale keyword was removed because the bug got commented on recently.
The bug assignee was notified.

Comment 21 Venkata Siva Teja Areti 2020-08-24 21:17:55 UTC
re-opening the issue as this is still an issue.

Comment 23 Stefan Schimanski 2020-08-31 10:08:46 UTC
How can we fix the unit tests? Can we exclude clusters that come from 4.1?

Comment 24 Venkata Siva Teja Areti 2020-09-01 16:13:19 UTC
I am not sure how to do that. Let's check with Ben to see if it is possible.

@Ben, Is it possible to exclude this test for clusters upgraded from 4.1? Please let us know if we have to talk to someone else regarding this.

Comment 25 Ben Parees 2020-09-01 17:57:21 UTC
not that i'm aware of unless the test itself can determine the provenance of the cluster and then just make its own choice to pass the test (i'm not sure if there's anything in the cluster itself that indicates what version the cluster started out as?)

Comment 26 Venkata Siva Teja Areti 2020-09-02 03:01:33 UTC
i think cluster version resource contains the upgrade history. maybe we could use that in the test.


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