Member Management Improvements

[grolu]

The current implementation of the project member management page has some limitations that we know about. Now with the requirement to connect service accounts from different namespaces, these limitations need to be resolved.

Planned changes

Project User Card

• Change the trash button to remove (as no actual deletion takes place this may causes confusion)
• Prevent to add service accounts via the add user dialog (prevent names that start with system:serviceaccount), the reason for this is that it may confuses users when they add a service account using this dialog and the connected account appears on a different card
• Show owner role (grayed out, not editable, with tooltip)

Service Accounts Card

Currently, the name of tis card is a bit misleading as we actually do not show (all) service accounts. We only show service accounts that have a role in the project, more precisely service accounts that have en entry of kind User in the member section of the project resource. This can lead to name clashes even if no service account with the name is listed.

• Show all service accounts, even those that have no role in the project
• Possibility to add service accounts without a role
• Deletion of service accounts need to be confirmed by entering the name
• Possibility to connect service accounts from different namespaces by using the full qualified name. Those service accounts need to have a role and cannot be deleted, so they also get a remove button
• Add service accounts to project resource with kind ServiceAccount
• Add possibility to rotate service account secrets
• Show service account details in row
• Support descriptions for Service Accounts (annotation)

Other Changes

• Add information about role types to help dialog
• Rename Technical Contact to owner on Administration page
• Remove Technical Contact Card

[grolu]

What about adding support for custom role management? We discussed this a while ago and the result was (as far as I know) that it should be relatively easy to support this in general, however there is still the question if thee dashboard should support this in the first place... Remember, the dashboard might not work properly when the custom roles are applied for a user, so we would need to place a hint somewhere.
@vlerenc what do you think, I think there is some pull and we could add this as part of the other improvements we are currently adding to the member management.

[vlerenc]

@grolu Yes, I think there is definitely a large pull to define custom roles with specific permissions as we might otherwise drown in a proliferation of roles. However, I am not fully aware of all consequences:

• Do we break down/have broken down permissions to RBAC; what the Garden cluster allows shall the dashboard not break and vice versa (today yes; with fine-grained roles also?), but some awkward requirements that cannot be mapped to RBAC should then be rejected, I guess
• Will the dashboard run apriori checks based on the user's role and associated permissions, hide or disable functions, or run all operations against the backend and fail late
• How to bring custom roles together with CAM support for project owners that we plan to offer out-of-the-box