Membership

Membership Page

The membership page should be organized similarly to the "other resources" page, with a table of objects and a dropdown to select which types of items to display
Initially all types of objects would be shown sorted by object type (Groups, Users, Service Accounts) and alphabetically within each of those groups.

Selecting edit from an object's kebab menu brings up a modal that shows all the roles currently attached to that object and enables users to remove them and attach more.
When applicable, role descriptions should be shown in the "add roles" dropdown with the associated role

Adding a new object behaves similarly to editing an object's roles but with an additional field for choosing which group or user to add (or two fields in the case of service accounts)
If more than one "member" object is added, all listed roles will be added to each object

Cluster roles should be viewable from this page so that people can view their details without having to have them assigned to a users first and clicking through. They could be automatically hidden and exposed with a checkbox, or they could be omitted entirely if showing them does not make sense.
Clicking on a role should link to the details page for that role.

The details tab for a role displays the description of the role as well as a list of the groups, users, and service accounts that have that role.

The permissions tab contains a table of all the resources that the role can act on and which permitted actions the role has for that resource.
an "All Actions" chip should be used when a resource has full permissions. The list of all permissions can be viewed on hover.
Resources should be grouped by API group and sorted alphabetically.
Only resources that the current role can act on should be displayed in this table.
In the special case that all resources have all permissions, only a single row will be shown in the table