RBAC docs

[nwneisen]

The RBAC docs are very basic. This issue is to start planning how they can be improved and what the structure will look like.

The RBAC migration from MKE3 is very complicated and will be the majority of the docs. Moving forward, we are using vanilla k8s RBAC and can mostly reference the actual k8s docs.

Below this line will be a living document of the RBAC docs information

Migration

MKE4 has dropped orgs and teams in favor of k8s AggregatedRoles. AggregatedRoles allows for the same RBAC hierarchy as what previously done in MKE3 using orgs and teams but now without the limitation of only 2 levels.

An org/team/user structure in MKE3 would've previously looked like the following

├── entireCompany (org)
│   ├── development (team)
│   │   ├── bob (user)
│   ├── production (team)
│   │   ├── bob (user)
│   │   ├── bill (user)
│   ├── sales (team)

The same structure can now be created using AggregatedRoles

├── entireCompany-org (AggregatedRole)
│   ├── development-team (AggregatedRole)
│   │   ├── bob (user)
│   ├── production-team (AggregatedRole)
│   │   ├── bob (user)
│   │   ├── bill (user)
│   ├── sales-team (AggregatedRole)

The upgrade process translates an existing org/team/user structure in this way.

Roles

Roles fit into the structure above by being bound to the aggregated roles. A role can be bound at any level in the hierarchy and its permissions will be granted to every member at that level.

├── entireCompany-org (AggregatedRole) -- entireCompany-org (RoleBinding) -- view (Role)

With this binding, everything within the entireCompany org will have view permissions. This includes the development-team, production-team, sales-team, bob, and bill

│   ├── development-team (AggregatedRole) -- development-team (RoleBinding) -- edit (Role)

This binding will only grant edit permissions to those within the development team. This would include only the user bob.

Swarm roles do not translate into k8s roles. When a swarm role is detected during the migration process, the none roles is used in its place. This allows the org/team/user structure to be maintained but users will need to create a role with the desired permissions and replace the none role where appropriate.

Fresh Cluster RBAC

A new cluster will use vanilla k8s RBAC. Information on this can be found in
https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles

An example might make sense here