Cloud RBAC

[schustmi]

Describe changes

This PR introduces changes to enable RBAC for all server endpoints.

RBAC

To check whether a user is allowed to perform an action on a resource, we verify that either

• the user is the owner of the resource (e.g. created the stack that he wants to read/update/delete)
• the user has an assigned role that gives them permission to perform the action. This is done using any concrete implementation of the zenml.zen_server.rbac.rbac_interface.RBACInterface interface.

Dehydration

Some of our response models contain other response models in some of their attributes. In some cases, users might have access to read the parent model but not the child models contained within it. To address this, we "dehydrate" any response model and redact information from child models which the user is not allowed to access.

Service accounts

Service accounts are currently stored in the server database which makes them incompatible with the Cloud RBAC backend (which requires an entry in the cloud user table). For this reason, service accounts currently are excluded from the RBAC and have full permissions.

Some additional changes that needed to be implemented

• Sharing of stacks, stack components and service connectors was removed. In case of overlapping entity names which are required to be unique, the owner id is appended as the suffix.
• Roles and teams were removed. This includes any kind of authorization on server endpoints when RBAC is disabled.
• The default stack and stack components are now created server-side. Additionally, there is just a single default stack per server and not one per user. This was necessary as some users might not have permissions to even create a stack, but the client code requires a working active stack in lots of places.
• To make caching less error-prone when using a shared local (e.g. default) stack, the client ID is not included in the cache key for local artifact stores.

Pre-requisites

Please ensure you have done the following:

• I have read the CONTRIBUTING.md document.
• If my change requires a change to docs, I have updated the documentation accordingly.
• If I have added an integration, I have updated the integrations table and the corresponding website section.
• I have added tests to cover my changes.
• I have based my new branch on develop and the open PR is targeting develop. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (add details above)

[stefannica]

Ready to land !

[bcdurak]

Amazing, amazing changes. It is great to see all of our previous discussions come alive in such an elaborate manner. I left a few comments, hope it helps.

I love the clean up as well ❤️

[github-actions]

E2E template updates in examples/e2e have been pushed.

[github-actions]

E2E template updates in examples/e2e have been pushed.