Hide Forgot
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:
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.
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
You're right, have a look at https://github.com/openshift/origin/pull/22814, I've followed the same approach upstream took.
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.
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.
singularName is always empty for non-CRD resources. How does kubectl handle this for other resources?
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.