You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
With this binding, everything within the entireCompany org will have view permissions. This includes the development-team, production-team, sales-team, bob, and bill
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.
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
The same structure can now be created using
AggregatedRoles
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.
With this binding, everything within the entireCompany org will have view permissions. This includes the development-team, production-team, sales-team, bob, and bill
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 thenone
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
The text was updated successfully, but these errors were encountered: