Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-4701

read-only update UX: confusing "Control plane is hosted" banner

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • 4.12
    • Management Console
    • None
    • Low
    • None
    • False
    • Hide

      None

      Show
      None

      Description of problem:

      In at least 4.12.0-rc.0, a user with read-only access to ClusterVersion can see a "Control plane is hosted" banner (despite the control plane not being hosted), because hasPermissionsToUpdate is false, so canPerformUpgrade is false.

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

      4.12.0-rc.0. Likely more. I haven't traced it out.

      How reproducible:

      Always.

      Steps to Reproduce:

      1. Install 4.12.0-rc.0
      2. Create a user with cluster-wide read-only permissions. For me, it's via binding to a sudoer ClusterRole. I'm not sure where that ClusterRole comes from, but it's:

      $ oc get -o yaml clusterrole sudoer
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        annotations:
          rbac.authorization.kubernetes.io/autoupdate: "true"
        creationTimestamp: "2020-05-21T19:39:09Z"
        name: sudoer
        resourceVersion: "7715"
        uid: 28eb2ffa-dccd-47e8-a2d5-6a95e0e8b1e9
      rules:
      - apiGroups:
        - ""
        - user.openshift.io
        resourceNames:
        - system:admin
        resources:
        - systemusers
        - users
        verbs:
        - impersonate
      - apiGroups:
        - ""
        - user.openshift.io
        resourceNames:
        - system:masters
        resources:
        - groups
        - systemgroups
        verbs:
        - impersonate
      

      3. View /settings/cluster

      Actual results:

      See the "Control plane is hosted" banner.

      Expected results:

      Possible cases:

      • For me in my impersonate group, I can trigger updates via the command-line by using --as system:admin. I don't know if the console supports impersonation, or wants to mention the option if it does not.
      • For users with read-only access in stand-alone clusters, telling the user they are not authorized to update makes sense. Maybe mention that their cluster admins may be able to update, or just leave that unsaid.
      • For users with managed/dedicated branding, possibly point out that updates in that environment happen via OCM. And leave it up to OCM to decide if that user has access.
      • For users with externally-hosted control planes, possibly tell them this regardless of whether they have the ability to update via some external interface or not. For externally-hosted, Red-Hat-managed clusters, the interface will presumably be OCM. For externally-hosted, customer-managed clusters, there may be some ACM or other interface? I'm not sure. But the message of "this in-cluster web console is not where you configure this stuff, even if you are one of the people who can make these decisions for this cluster" will apply for all hosted situations.

            rhn-engineering-rhamilto Robb Hamilton
            trking W. Trevor King
            Xiyun Zhao Xiyun Zhao
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: