rancher / elemental-ui

Rancher UI Plugin for Elemental
Apache License 2.0
12 stars 12 forks source link

Wrong default cloud config file with standard user #175

Closed juadk closed 5 months ago

juadk commented 6 months ago

Description

Standard user with elemental admin role does not see the expected default cloud-config file:

config:
  cloud-config:
    users:
    - name: root
      passwd: root
  elemental:
    install:
      poweroff: true
      device: /dev/nvme0n1

instead of:

config:
  cloud-config:
    users:
    - name: root
      passwd: root
  elemental:
    install:
      reboot: true
      device-selector:
      - key: Name
        operator: In
        values:
        - /dev/sda
        - /dev/vda
        - /dev/nvme0
      - key: Size
        operator: Gt
        values:
        - 25Gi
      snapshotter:
        type: btrfs

There is no issue if you use the admin account. Probably introduced by https://github.com/rancher/elemental-ui/pull/169

Env

Rancher: 2.8.3 Elemental dev UI: 1.3.1-rc4 Elemental operator: 1.6.0

davidcassany commented 6 months ago

I think the issue is that the issue is elemental-admin role does not see the elemental-operator deployment.

davidcassany commented 6 months ago

@aalves08 I have been thinking a bit more regarding that and I was wondering about the UI test to verify elemental-operator is actually installed. IIRC this was done by checking the existence of certain CRD. Can you confirm that? which CRD is actually verified? I was wondering, what if we try to annotate such a CRD to include the elemental-operator version? In addition, then we could even use that at helm chart level to prevent a mismatch between the version of the crds chart with the deployment chart.

aalves08 commented 6 months ago

@aalves08 I have been thinking a bit more regarding that and I was wondering about the UI test to verify elemental-operator is actually installed. IIRC this was done by checking the existence of certain CRD. Can you confirm that? which CRD is actually verified? I was wondering, what if we try to annotate such a CRD to include the elemental-operator version? In addition, then we could even use that at helm chart level to prevent a mismatch between the version of the crds chart with the deployment chart.

the resource is catalog.cattle.io.app, we check for the existance of an installed app here with the id elemental-operator. We combine that with also the existance of a schema for an Elemental resource (ex: machine inventories). The goal is to match install + permissions.

But the problem is the same... If a user doesn't have access to that cluster (99% of the times it's the local one) we cannot definitively assert the installation and/or access is correct.

I've had another idea (non-hacky imo), but I've asked Neil to give his opinion on it before I present it to you guys.

Apart from that I can only come up with a couple of very hacky solutions which, imo, shouldn't be considered so that we don't introduce a bad pattern for the future 💦 😓

frelon commented 6 months ago

We are probably missing a read permission on that resource for the elemental administrator globalrole, I will try to add it locally and see if I can reproduce this.

aalves08 commented 6 months ago

Connected to https://github.com/rancher/elemental-operator/pull/712

juadk commented 5 months ago

All is good from my side, the user account is enabled back here https://github.com/rancher/elemental/pull/1412