Bug 1699285 - who-can command gives incorrect output
Summary: who-can command gives incorrect output
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.1.0
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
: 4.3.0
Assignee: Maciej Szulik
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-12 10:21 UTC by Arnab Ghosh
Modified: 2020-05-04 14:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-04 14:23:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 4058371 0 None None None 2019-04-12 11:05:53 UTC

Description Arnab Ghosh 2019-04-12 10:21:07 UTC
Description of problem:

The output of 'oc adm policy who-can create template' command is incorrect. I have created a new service account in a new project and attached role[1] to it. After that I ran who-can command which is not listing the service account but after I login as that service account and try to create template, I could.

[1] clusterrole to provide template creation ability
----------------------------------------------------

apiVersion: authorization.openshift.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: 2019-04-12T07:32:12Z
  name: create-template-clusterrole
  resourceVersion: "617221"
  selfLink: /apis/authorization.openshift.io/v1/clusterroles/bmw%3Atemplate-manager
  uid: 166df6ab-5cf5-11e9-9c73-fa163ec69827
rules:
- apiGroups:
  - template.openshift.io
  attributeRestrictions: null
  resources:
  - templates
  verbs:
  - '*'


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

oc v4.0.0-0.79.0
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://aprajapatest1-api.aws.oshift.net:6443
kubernetes v1.11.0+8868a98a7b

How reproducible:

Always

Steps to Reproduce:
1. create a new project
2. create a new service account
3. Attach role[1] to the new service account
4. Check output of 'oc adm policy who-can create template -n <project_name>' command. Check whether the new service account is listed or not
5. Login as the service account and try to create a template

Actual results:

User/SA who can create template is not listed

Expected results:

output of 'oc adm policy who-can create template -n <project_name>' command should list all user/SA who can create

Additional info:

Comment 1 Maciej Szulik 2019-04-16 10:52:26 UTC
From what I see in the code there are some differences between localRAR and RAR. I'm passing this over to the auth team to clear this up.

Comment 2 Mo 2019-05-09 18:37:40 UTC
Maciej, is there some special code in oc that is failing to pluralize template:



$ oc adm policy who-can create template

resourceaccessreviewresponse.authorization.openshift.io/<unknown> 

Namespace: foobar
Verb:      create
Resource:  template           #  <----- note the lack of expansion for template

Users:  system:admin
        system:serviceaccount:kube-system:clusterrole-aggregation-controller
        system:serviceaccount:openshift-apiserver-operator:openshift-apiserver-operator
        system:serviceaccount:openshift-apiserver:openshift-apiserver-sa
        system:serviceaccount:openshift-authentication-operator:authentication-operator
        system:serviceaccount:openshift-authentication:oauth-openshift
        system:serviceaccount:openshift-cluster-version:default
        system:serviceaccount:openshift-controller-manager-operator:openshift-controller-manager-operator
        system:serviceaccount:openshift-kube-apiserver-operator:kube-apiserver-operator
        system:serviceaccount:openshift-kube-apiserver:installer-sa
        system:serviceaccount:openshift-kube-controller-manager-operator:kube-controller-manager-operator
        system:serviceaccount:openshift-kube-controller-manager:installer-sa
        system:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operator
        system:serviceaccount:openshift-kube-scheduler:installer-sa
        system:serviceaccount:openshift-machine-config-operator:default
        system:serviceaccount:openshift-network-operator:default
        system:serviceaccount:openshift-operator-lifecycle-manager:olm-operator-serviceaccount
        system:serviceaccount:openshift-service-ca-operator:service-ca-operator
        system:serviceaccount:openshift-service-catalog-apiserver-operator:openshift-service-catalog-apiserver-operator
        system:serviceaccount:openshift-service-catalog-controller-manager-operator:openshift-service-catalog-controller-manager-operator
Groups: system:cluster-admins
        system:masters



$ oc adm policy who-can create templates

resourceaccessreviewresponse.authorization.openshift.io/<unknown> 

Namespace: foobar
Verb:      create
Resource:  templates.template.openshift.io           #  <----- note the correct expansion for templates

Users:  system:admin
        system:serviceaccount:foobar:mosa
        system:serviceaccount:kube-system:clusterrole-aggregation-controller
        system:serviceaccount:openshift-apiserver-operator:openshift-apiserver-operator
        system:serviceaccount:openshift-apiserver:openshift-apiserver-sa
        system:serviceaccount:openshift-authentication-operator:authentication-operator
        system:serviceaccount:openshift-authentication:oauth-openshift
        system:serviceaccount:openshift-cluster-version:default
        system:serviceaccount:openshift-controller-manager-operator:openshift-controller-manager-operator
        system:serviceaccount:openshift-infra:template-instance-controller
        system:serviceaccount:openshift-infra:template-instance-finalizer-controller
        system:serviceaccount:openshift-kube-apiserver-operator:kube-apiserver-operator
        system:serviceaccount:openshift-kube-apiserver:installer-sa
        system:serviceaccount:openshift-kube-controller-manager-operator:kube-controller-manager-operator
        system:serviceaccount:openshift-kube-controller-manager:installer-sa
        system:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operator
        system:serviceaccount:openshift-kube-scheduler:installer-sa
        system:serviceaccount:openshift-machine-config-operator:default
        system:serviceaccount:openshift-network-operator:default
        system:serviceaccount:openshift-operator-lifecycle-manager:olm-operator-serviceaccount
        system:serviceaccount:openshift-service-ca-operator:service-ca-operator
        system:serviceaccount:openshift-service-catalog-apiserver-operator:openshift-service-catalog-apiserver-operator
        system:serviceaccount:openshift-service-catalog-controller-manager-operator:openshift-service-catalog-controller-manager-operator
Groups: system:cluster-admins
        system:masters

Comment 3 Maciej Szulik 2019-05-10 14:44:45 UTC
You're right, have a look at https://github.com/openshift/origin/pull/22814, I've followed the same approach upstream took.

Comment 4 Maciej Szulik 2019-05-10 17:18:28 UTC
The problem seems to be with the MultiRESTMapper, it matches both processedtemplates and templates
and since it can't pick one or the other it fails with no match. I'll look into how we can make it better.

Comment 5 Maciej Szulik 2019-05-10 20:45:56 UTC
The root cause for this problems is that we don't have singularName defined for templateinstance:

{
  "name": "processedtemplates",
  "singularName": "",
  "namespaced": true,
  "kind": "Template",
  "verbs": [
    "create"
  ]
}

so this ends up picking Kind in unsafe fashion to create that singularName, 
see https://github.com/openshift/origin/blob/66bcaddbb4264915cfeb798860f097ce042e6015/vendor/k8s.io/kubernetes/staging/src/k8s.io/client-go/restmapper/discovery.go#L108-L112

To solve this we should implement SingularNameProvider similarly how we have CategoryProvider or ShortNameProvider which is then wired in installer,
see https://github.com/openshift/origin/blob/66bcaddbb4264915cfeb798860f097ce042e6015/vendor/k8s.io/kubernetes/staging/src/k8s.io/apiserver/pkg/endpoints/installer.go#L855-L860.

Comment 6 Stefan Schimanski 2019-07-03 08:47:53 UTC
singularName is always empty for non-CRD resources. How does kubectl handle this for other resources?

Comment 8 Maciej Szulik 2020-05-04 14:23:39 UTC
This bug hasn't had any activity in quite some time. 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 closing this bug.

If you have further information on the current state of the bug, please add it
and reopen this bug. 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.


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