Yeah, we could do this. There's a similar role we have added people to in the past I think called cluster-monitor? But we would need to look up the differences...

More visibility is great IMHO.

Yep, was talking with dkirwan about this a bit ago and apparently at the moment it's an all or nothing system where you either have admin and can read/write to everything or not.

I would be interested in that as well (for getting backtrace when we break stuff for username change), but there is indeed leak risks, and stuff like this.

So I took a quick look at the cluster-reader role on the cluster I managed (installed 5 years ago, I assume this was kept up to date), I see the following permission:

- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - persistentvolumeclaims
  - persistentvolumeclaims/status
  - pods
  - replicationcontrollers
  - replicationcontrollers/scale
  - serviceaccounts
  - services
  - services/status
  verbs:
  - get
  - list
  - watch

I have some concerns on the configmap part, because there is plenty of configmaps with information that should be stored as a secret (I found 17 before I ran out of power on my laptop and had to get lunch at Flock). For example:

https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/the-new-hotness/templates/configmap.yml.j2#_15

https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/the-new-hotness/templates/config.toml#_107

Or, various alembic.ini files who are template and dropped in a configMap would be leaking postgres passwords (which is outside of the cluster), etc.

Yeah, cluster reader is pretty privileged in that sense.

Perhaps we could reframe this... what sorts of use cases do we want to handle here?

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/infra/tickets/issues/12576

Please continue any further discussion there.