Description of problem: A regular user cannot use "virtctl ssh" to connect to a VM: ~~~ $ virtctl ssh --username=cloud-user rhel9-casual-cat can't access VMI rhel9-casual-cat: virtualmachineinstances.subresources.kubevirt.io "rhel9-casual-cat" is forbidden: User "jorti" cannot get resource "virtualmachineinstances/portforward" in API group "subresources.kubevirt.io" in the namespace "jorti" ~~~ Version-Release number of selected component (if applicable): OpenShift Virtualization 4.11.2 How reproducible: Always Steps to Reproduce: 1. Using a regular user with admin privileges in a project, try to connect to a VM: $ virtctl ssh --username=cloud-user rhel9-casual-cat Actual results: can't access VMI rhel9-casual-cat: virtualmachineinstances.subresources.kubevirt.io "rhel9-casual-cat" is forbidden: User "jorti" cannot get resource "virtualmachineinstances/portforward" in API group "subresources.kubevirt.io" in the namespace "jorti" Expected results: No errors Additional info: It looks like a fix for this has been already merged upstream: https://github.com/kubevirt/kubevirt/pull/7675
How was the user account created? Were any roles assigned to it? Without any roles it will not have any permissions. Also can you please define "a regular user with admin privileges"? A user can either be an admin or a regular/unprivileged user. Currently at least role 'kubevirt.io:edit' is needed to access portforwardings. With this PR [1] it would become possible to access portforwarding with role 'kubevirt.io:view'. [1] https://github.com/kubevirt/kubevirt/pull/9071
Okay, I think I found the issue. The default cluster roles grant priviliges with the wrong verb on the required API endpoints. This PR should fix it: https://github.com/kubevirt/kubevirt/pull/9120
(In reply to Felix Matouschek from comment #1) > How was the user account created? Were any roles assigned to it? Without any > roles it will not have any permissions. > Also can you please define "a regular user with admin privileges"? A user > can either be an admin or a regular/unprivileged user. For the record, this is the rolebinding of my test user: ~~~ apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: creationTimestamp: "2023-01-13T08:45:38Z" name: jorti-admin namespace: jorti resourceVersion: "83755649" uid: 9146690a-b999-478a-a76b-b1544ade511d roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: jorti ~~~
Setup: 1. Create a rolebinding for any regular user. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: test-geetika-admin namespace: testing-cnv uid: d443e6c2-67a0-4783-9c39-daa5d00643cd resourceVersion: '1440834' creationTimestamp: '2023-05-25T11:06:39Z' managedFields: - manager: Mozilla operation: Update apiVersion: rbac.authorization.k8s.io/v1 time: '2023-05-25T11:06:39Z' fieldsType: FieldsV1 fieldsV1: 'f:roleRef': {} 'f:subjects': {} subjects: - kind: User apiGroup: rbac.authorization.k8s.io name: geetika-test roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin 2. setup oauth to use htpasswd for the user(Note any other identity providers can also be use like github, basic auth,ldap) spec: identityProviders: - htpasswd: fileData: name: htpasswd-k8s58 mappingMethod: claim name: geetika-test type: HTPasswd Note : Generate HTPasswd password from any generator Login with user : geetika-test with htpasswd(plain text) 1. ssh-keygen -f key_file_test_geetika 2. oc create secret generic my-pub-key-test-geetika --from-file=key1=key_file_test_geetika.pub -n testing-cnv 3. Create a VM with public key(key_file_test_geetika.pub) in authorized key 4. wait for vm to be up. 5 try to access console using : $ virtctl ssh --username=cloud-user rhel9-mushy-leopard -n testing-cnv -i key_file_test_geetika $ oc get vmi -n testing-cnv NAME AGE PHASE IP NODENAME READY rhel9-mushy-leopard 69m Running 10.129.2.251 c01-gk411bug-rf26w-worker-0-f4tcr True 6. Login should be succcessful.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Virtualization 4.11.6 security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:5103