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:
@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.
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
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.