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

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


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



      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:


      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
          rbac.authorization.kubernetes.io/autoupdate: "true"
        creationTimestamp: "2020-05-21T19:39:09Z"
        name: sudoer
        resourceVersion: "7715"
        uid: 28eb2ffa-dccd-47e8-a2d5-6a95e0e8b1e9
      - apiGroups:
        - ""
        - user.openshift.io
        - system:admin
        - systemusers
        - users
        - impersonate
      - apiGroups:
        - ""
        - user.openshift.io
        - system:masters
        - groups
        - systemgroups
        - 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
            0 Vote for this issue
            7 Start watching this issue