Bug 1824911

Summary: PersistentVolume yaml editor is read-only with system:persistent-volume-provisioner ClusterRole
Product: OpenShift Container Platform Reporter: Eric Fried <efried>
Component: Management ConsoleAssignee: Samuel Padgett <spadgett>
Status: CLOSED ERRATA QA Contact: Xiyun Zhao <xiyuzhao>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3.0CC: afrahman, aos-bugs, jokerman, nthomas, rhamilto, spadgett, yapei
Target Milestone: ---Flags: xiyuzhao: needinfo-
Target Release: 4.8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 4.8.0-0.nightly-2021-04-09-222447 Doc Type: Bug Fix
Doc Text:
The web console YAML editor was incorrectly set to read-only mode when a user had permission to create a resource, but not permission to edit it. The editor content is now correctly editable when the user has create access for the resource.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-07-27 22:32:23 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:
Bug Depends On:    
Bug Blocks: 1942027    

Description Eric Fried 2020-04-16 16:17:50 UTC
Description of problem:

When I have permission to create PVs via a ClusterRoleBinding tying my group to the system:persistent-volume-provisioner role, the YAML editor in the Storage => PersistentVolumes => Create Persistent Volume window is read-only, in the sense that I cannot edit the content.

I am still able to drag-and-drop a premade file into the editor and its content appears properly.

I am still able to create the PV successfully after doing that, as well as from the generic `+` in the top right corner (whose editor is writable), and the command line.

When I'm a member of osd-sre-cluster-admins, the editor is writable. I haven't tried to isolate what osd-sre-cluster-admins have that's making the difference.

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

How reproducible:
Every time.

Steps to Reproduce:
On qaprodauth (haven't tried this in prod):
1. Create AWS-backed OSD cluster (haven't tried with other combinations)
2. Log into the web UI as OpenShift_SRE, navigate to Storage => Persistent Volumes. The "Create Persistent Volume" button is absent, as expected.
3. Elevate privileges (I do this by adding self to the osd-sre-cluster-admins group)
4. Create a ClusterRoleBinding like:

 kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: system:persistent-volume-provisioner-for-sre
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: system:persistent-volume-provisioner
 subjects:
 - apiGroup: rbac.authorization.k8s.io
   kind: Group
   name: osd-sre-admins

5. Drop privileges (remove self from osd-sre-cluster-admins)
6. Refresh the web UI or log in again.
7. The Storage => Persistent Volumes page now has the "Create Persistent Volume" button. Punch it.
   a. Attempt to edit the text in the YAML editor. This fails (popover complains that the editor is read-only).
   b. Open a file explorer, find a YAML file for a legit PV, and drag-and-drop it into the editor. This succeeds (the text is replaced with the file contents).
   c. Punch the Create button. This works -- the PV is created.

Actual results:
Per 7.a. the YAML editor is read-only.

Expected results:
The YAML editor is writable.

Additional info:
We originally observed this via an OAuth'd user created in `dedicated-admins` to simulate the customer. In that scenario, the ClusterRoleBinding differed only in that the subjects[0].name was `dedicated-admins` rather than `osd-sre-admins`. Otherwise the observed behavior was the same.

Comment 1 Robb Hamilton 2020-05-07 14:33:38 UTC
Reassigning to Console Storage Plugin since they own this functionality.

Comment 2 Nishanth Thomas 2020-05-12 11:32:33 UTC
Low priority issue, moving to 4.6

Comment 3 Nishanth Thomas 2021-02-13 08:46:16 UTC
Moving out to 4.8

Comment 4 Pranshu Srivastava 2021-02-20 19:55:15 UTC
Hello Eric.


I don't have access to some of the resources (namely OSD cluster, Openshift_SRE credentials, and the apiGroup privileges) that are described in your aforementioned comment, hence I'm unable to reproduce this on my machine.

Would it be possible for you to grant me testing access to them (or a similar environment that depicts your bug successfully, maybe a VM?) so that I can take a look at what may be causing this bug?

Comment 5 Pranshu Srivastava 2021-02-24 07:47:20 UTC
This is a generic issue, it happens with all the resources. Moving it to Management Console.

Comment 6 Robb Hamilton 2021-02-24 15:48:48 UTC
Will investigate next sprint.

Comment 7 Robb Hamilton 2021-03-15 14:43:20 UTC
Reassigning to Jakub since he's better equipped to fix RBAC issues.

Comment 8 Samuel Padgett 2021-03-22 13:57:12 UTC
Can you confirm you can edit the resource via the CLI? We rely on self-subject access reviews to determine if the editor should be read-only. Note that you need `update` authority on the resource, not just `patch`.

Comment 9 Eric Fried 2021-03-22 15:28:20 UTC
I've spun up a fresh cluster to test this. Let me know if you would like access to poke around.

> Can you confirm you can edit the resource via the CLI?

Indeed, I cannot edit PVs (in the UI or CLI) as the system:persistent-volume-provisioner clusterrole does not have PV patch or update permissions:

```
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - create
  - delete
  - get
  - list
  - watch
```

When I add those permissions to the clusterrole and reload the console, the editor becomes writable (and editing via the CLI becomes possible).

So it sounds like the bug is that the editor in the "Create" page should rely on the `create` verb rather than `update`/`patch`.

Comment 10 Samuel Padgett 2021-03-22 18:46:49 UTC
Yeah, I see the problem. You're right: we're incorrectly checking update permission when creating a resource via the YAML editor.

Comment 12 Xiyun Zhao 2021-04-12 03:37:15 UTC
@Samuel Padgett 
I think the action of 'create' verb for the role is still doesn't have the proper behavior, ping me if there is any misunderstanding here.
On current behavior, normal user will not able to create PV only after actions of '-update' and '-patch' verb are granted to related Role once.

Build version: 4.8.0-0.nightly-2021-04-09-222447

Verify steps:
1. Login to the OCP as administrator.
2. Create a Groups with a normal user
3. Create a RoleBindings for the Group with name (system:persistent-volume-provisioner-for-sre) and Role ref (system:persistent-volume-provisioner)
4. Checking Rules of Role red(syste:persistent-volume-provisioner), make sure only create, delete, get, list, watch actions has been granted to the Resources (persistentvolumes)
5. Re-login the OCP as a normal user testuser0
6. Verify if user is able to create PV on page, and check if 'Create PersistentVolume' button is showable and workable
   Issue: the 'Create PersistentVolume' button is showable, but block/unable for click
7. Re-login the OCP as admin
8. Add - update and - patch  actions for persitentvolumes resources for roles of system:persistent-volume-provisioner
9. Re-login OCP as normal user testuser0
10. Verify if user is able to create/edit PV on page normally. then remove all created PV.
11. Re-login OCP as admin, remove -update and -patch actions for persitentvolumes resources for roles of system:persistent-volume-provisioner.
12. Re-login as normal user
13. Verify if user is able to create/edit PV normally. 

Result:
1. For Step6: User is unable to create PV even if 'create' actions is granted, the 'Create PersistentVolume' button is showable, but block for create.
2. For Step 10 & 13: user is able to create and edit PV normally.

Comment 13 Samuel Padgett 2021-04-12 13:04:33 UTC
What you're seeing looks like an unrelated issue where the "getting started" message is displaying because the user hasn't created a project yet. After I create a project, I am able to create the PersistentVolume. The original bug was specifically that the YAML editor was read-only, which was the scope of the bug fix. We can track the other "getting started" behavior in a separate bug. It's currently working as designed, but it does block you from doing some things until you create a project.

Moving back to ON_QA.

Comment 14 Xiyun Zhao 2021-04-13 06:25:19 UTC
@Samuel Padgett, yes, you're right, thanks for your information.

Bug has been verified and fixed on payload 4.8.0-0.nightly-2021-04-09-222447

Verify Step:
1. Login to the OCP as administrator.
2. Create a Groups with a normal user
3. Create a RoleBindings for the Group with name (system:persistent-volume-provisioner-for-sre) and Role ref (system:persistent-volume-provisioner)
4. Checking Rules of Role red(syste:persistent-volume-provisioner), make sure only create, delete, get, list, watch actions has been granted to the Resources (persistentvolumes)
5. Re-login the OCP as a normal user testuser0, create a new project
6. Navigate to page of PV, verify if user is able to create PV on page, and check if 'Create PersistentVolume' button is showable. ​
7. Re-login the OCP as admin
8. Add - update and - patch  actions for persitentvolumes resources for roles of system:persistent-volume-provisioner
9. Re-login OCP as normal user testuser0
10. Verify if user is able to edit PV on page normally
11. Login OCP by using CLI, use below command to create PV, verify if user could create PV successfully by using CLI.
    oc create -f testpv

    $ cat testpv 
    apiVersion: v1
    kind: PersistentVolume
    metadata:
       name: example
    spec:
       capacity:
         storage: 5Gi
       accessModes:
         - ReadWriteOnce
       persistentVolumeReclaimPolicy: Retain
       storageClassName: slow
       nfs:
         path: /tmp
         server: 172.17.0.2

Result:
1. For step 6: user is able to create PV successfully
2. For step 10: user is able to edit and update PV successfully, YAML is editable.
3. For step 11: user is able to create PV by using CLI successfully

Comment 17 errata-xmlrpc 2021-07-27 22:32:23 UTC
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 Container Platform 4.8.2 bug fix and security 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-2021:2438