Update predefined cluster roles to consider all important CAPI CRs

[mogottsch]

rbac-operator creates a number of "predefined" cluster roles when it first runs on a cluster (those in defaultnamespace controller). These cluster roles give access to specific groups of resources, e.g. write-nodepools should give access to machinepools and everything related.

Some of these cluster roles are quite outdated and do not give access to all related CRs defined in CAPI clusters. We have to check which CRs are currently not covered and update the existing cluste roles accordingly.

[mogottsch]

I have created a list of all CRs in the cluster.x-k8s.io group, that are on at least one of our CAPA MCs.

crd	clusterrole
awsclustercontrolleridentities
awsclusterroleidentities
awsclusters	write-clusters
awsclusterstaticidentities
awsclustertemplates
awsfargateprofiles
awsmachinepools
awsmachines
awsmachinetemplates
awsmanagedclusters
awsmanagedcontrolplanes
awsmanagedmachinepools
azureclusteridentities
azureclusters	write-clusters
azureclustertemplates
azuremachinepoolmachines
azuremachinepools	write-nodepools
azuremachines	write-clusters
azuremachinetemplates
azuremanagedclusters
azuremanagedcontrolplanes
azuremanagedmachinepools
clusterclasses
clusterresourcesetbindings
clusterresourcesets
clusters	write-clusters
eksconfigs
eksconfigtemplates
extensionconfigs
ipaddressclaims
ipaddresses
kubeadmconfigs
kubeadmconfigtemplates
kubeadmcontrolplanes
kubeadmcontrolplanetemplates
machinedeployments	write-nodepools
machinehealthchecks
machinepools	write-nodepools
machines
machinesets
providers
vsphereclusteridentities
vsphereclusters
vsphereclustertemplates
vspheredeploymentzones
vspherefailuredomains
vspheremachines
vspheremachinetemplates
vspherevms

Next, I will investigate the CRs that are not yet covered by any cluster role.

[mogottsch]

I talked to @anvddriesch and we came to the following conclusion:

The cluster roles that manage access to CAPI-related resources are write-nodepools and write-clusters. In vintage those managed access to cluster or nodepool-related resources like cluster, machinedeployment, etc... However, in CAPI, all those resources are managed through the cluster-apps (e.g., cluster-aws). For example, to create a new nodepool, you would not create a new resource but edit the values of the cluster app. Therefore, the only access necessary would be to create/delete cluster-apps and modify their config values. However, one might also want to view the resources created by the cluster-apps which would require read access to those.

As this is closely related to UX, I would like to bring this to SIG-UX for discussion on how the UX vision is in general for creating/modifying CAPI clusters.

[mogottsch]

We talked about this in Sig UX sync and came to the following conclusion:

• I will investigate how many customers use write-nodepools and write-clusters separately
• The underlying problem is about how we manage fine-grained control over cluster and cluster-related components in CAPI. We think that discussing this is important as we don't want to remove useful features going from vintage to CAPI.
• I will bring this to Sig Product sync.

[mogottsch]

I've checked the following installations:

• akita
• alpaca
• anaconda
• anchovy
• anteater
• antelope
• anzu
• argali
• bandicoot
• buffalo
• cuckoo
• eagle
• flamingo
• fox
• gaggle
• gaia
• gauss
• giraffe
• glippy
• goku
• golem
• goku
• golem
• gollum
• gopher
• gorilla
• gremlin
• grizzly
• kudu
• leopard
• potato
• snail
• valkyrie
• viking
• visitor

For each of those the only reference of write-nodepool and write-clusters was a cluster role binding for the automation service account in the default namespace. Therefore, there is no evidence of anyone using write-nodepools and write-clusters separately.

[mogottsch]

@gawertm I just realized that for the next two weeks, I cannot make it to Sig product sync. Is this something you could bring there?

Summary of what I want to talk about: In vintage we two cluster roles write-nodepools and write-clusters. These give access to cluster and nodepool related resources respectively. With these roles you can therefore create clusters and nodepools. Because the two roles are separate, it was possible to let someone only create nodepools, but not clusters. In CAPI this will be more difficult, because you create clusters and nodepools only through the cluster-app and its configmap.

The question is whether we still want to keep providing these separate cluster roles. They were meant to be used by customers.

As stated in the above comment, in all installations that I checked write-nodepool and write-clusters were always used together. Furthermore, those roles were only bound to the automation ServiceAccount in the default namespace, which I think is also created by rbac-operator. Therefore, no one uses them manually.

[gawertm]

sure, lets discuss (maybe in refinement tomorrow). maybe we can decide as bigmac, otherwise I'll bring it to sig product

[gawertm]

outcome of refinement: we want to check if we can remove the two roles and maybe include the permissions in another role that is bound to the Automation SA, if not already existing. this will be for vintage, for CAPI this is different anyways and we wont need the two roles anymore as they are not used in any case

[mogottsch]

The cluster roles write-clusters and write-nodepools are removed from rbac-operator.

In addition, I did a clean-up, because removing them from rbac-operator won't remove them from the MCs. All installation expect

• guppy
• icecream are cleaned.

I couldn't log in to these two.