Overview of current RBAC Capabilities

[gawertm]

User Story

As a Potential customer I want to know what RBAC Capabilities Giantswarm offers so that I can evaluate if it fits my requirements

requirements typically are that A customer has 100 developers / PEs across 10 teams. And they want to efficiently manage which team can do what on which clusters. This should be centrally defined in one place and also integrated with their SSO solution.
e.g. every team gets read access to all clusters, each team gets write access to "their" cluster and an admin team gets write access to all clusters
other requirements: some teams want to work on the same cluster but need isolation via namespaces

Task

• write down what is currently possible on MCs (e.g. with organizations, but also with standard RBAC via GitOps)
• Write down what is currently possible on WCs
• how can we demo this easily?
• the outcome must be easily/clearly understandable overview, with help of sales even into a public doc
• we will then take this as a basis for discussions with Sales on what customers usually ask for and if this is enough or where we can potentially add better automation (e.g. in WCs)

[mogottsch]

I've aggregated information on how to setup an installation with the requirements mentioned in the example above.

Requirements

• (0) SSO should be used to sign in
• (1) every team gets read access to all clusters
• (2) each team gets write access to "their" cluster
• (3) an admin team gets write access to all clusters
• (4) some teams want to work on the same cluster but need isolation via namespaces

RBAC Capabilities on MCs

• SSO is enabled by default, to configure it for customers the connector information has to be entered in the dex-operator config (if the provider is compatible with dex-operator) or directly in the dex-app config (0)
• create a ClusterRoleBinding that binds the read-all ClusterRole to each group (team) (1)
• create a RoleBinding that binds the cluster-admin role to the group (team) in the respective team's namespace (2)
• set the write_all_group value in the config of rbac-operator to the admin group (3)

RBAC Capabilities on WCs

• enable SSO by installing auth-bundle (0)

  • if dex-operator is configured properly on the MC then no further configuration is necessary
  • if not the connector information has to be configured in the configuration of dex-app

• RBAC configuration on WCs through MC

• use extra rbac-bootstrap-app to create (cluster)rolebindings on WCs from MCs

  • create ClusterRoleBinding that binds the view ClusterRole to each group (team) (1)
  • create ClusterRoleBinding that binds the cluster-admin ClusterRole to the group (team), that owns the cluster (2)
  • create RoleBinding that binds the cluster-admin ClusterRole to the group (team), that owns the namespace in the namespace (4)
  • the customer write_all_group should have admin permissions by default on the cluster (3)

[OnurYilmazGit]

https://docs.google.com/document/d/1315bRU14KsW0oiu_UWGAyJCn1h8xTCLp6fVLOW4sEtU/edit?usp=sharing

[OnurYilmazGit]

Questionnaire
https://docs.google.com/forms/d/1rvAQhOGi3lxHnL1_MPMSn2KGuwa-L336-HIRmYXm7Nc/edit

[gawertm]

@alex-dabija @puja108 , can you have a look at this questionnaire? we are planning to send it to customers (after aligning with team teddyfriends) to collect requirements. But maybe some things you would like to add from a product perspective?

[puja108]

Depends a lot on what you aim to learn with this. Reading the questionnaire, I'm not sure what the learning goal is, but I guess you have one. It looks like a rather technical and process focus, but might be a bit too simplified to get good data in some cases, e.g. responsibility might be split, like there might be security and IAM teams centrally but they care about IdP and OIDC setups, the actual RBAC might rather be responsibility of the platform team. Where it will get you good data is on how and where the actual RBAC yaml is managed.

From my side, to help with your teams product discovery it might be interesting to broaden the research and explore how access is managed in a wider sense. I'd aim to know things like: if users are assigned roles individually vs via groups, how groups are managed (new groups in the IdP vs map existing groups), who manages them, and what kind of access is usually given out (e.g. namespace admin, multi-namespace, read on all,...).

That said, coming back to my first line, if your goal of inquiry is a different one, then my areas of inquiry might not well integrate into the same questionnaire.

[gawertm]

So our goal is mainly to find out what tooling customers have in place, what are their challenges and what are their goals. We do ask here and there some additional questions but key for us really, are those

WDYT?

[puja108]

fine by me, don't wanna make it too overwhelming, so good to keep it short like this

[gawertm]

we are putting this one on hold until it is clear, that BigMac will be responsible for it also in the future

[stone-z]

RBAC effort has been de-prioritized, so we will close this for now and resurrect it if needed