Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1486142

Summary:	cluster-reader is suggested to have permission to run `oadm top node/pod`
Product:	OpenShift Container Platform	Reporter:	Xingxing Xia <xxia>
Component:	apiserver-auth	Assignee:	Simo Sorce <ssorce>
Status:	CLOSED NOTABUG	QA Contact:	Chuan Yu <chuyu>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.6.1	CC:	aos-bugs, jliggitt, mkhan
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-09-09 20:05:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Xingxing Xia 2017-08-29 07:26:08 UTC

Description of problem:
Currently cluster-reader does not have permission to run `oadm top node/pod` until the clusterrole is manually edited to add `services/proxy` item.
It is suggested to let it have the permission from the view of its role name's semantic meaning.

BTW, this issue is found and suggested when cluster-reader account (granted by email https://url.corp.redhat.com/b289d64) is used to check the top pod/nodes in cluster

Version-Release number of selected component (if applicable):
v3.6.173.0.5

How reproducible:
Always

Steps to Reproduce:
1. Give user cluster-reader
oadm policy add-cluster-role-to-user cluster-reader xxia
2. Login with the user and run top pod/node
For the command, see comment https://bugzilla.redhat.com/show_bug.cgi?id=1470003#c10

Actual results:
2. Cluster reader cannot see top pods/nodes. Details see https://bugzilla.redhat.com/show_bug.cgi?id=1470003#c10

Expected results:
2. Cluster reader should see.

Additional info:

Comment 1 Mo 2017-09-09 03:58:37 UTC

@Jordan pods/proxy and services/proxy are marked as escalating resources in TestClusterReaderCoverage.  I assume this is because the proxy capabilities could be abused to gain access to secrets?  Could you give specifics?

@Xingxing I plan to close this once I get more info from Jordan.

Comment 2 Jordan Liggitt 2017-09-09 04:06:27 UTC

proxying to arbitrary services and pods is considered escalating because it allows access to unknown capabilities, and we cannot guarantee the access is read-only

Comment 4 Mo 2017-09-09 20:05:48 UTC

Cluster reader must be guaranteed to only have read access to resources.  Since that cannot be determined for the pod/service proxy sub resources, we cannot add those permissions to it.