Intro to Permissions
Verta’s platform permission and access control systems are robust and incredibly flexible. This document offers a deep dive into the full functionality of the permission system and related features.
This permissions system will become available to most customers in March of 2023. Work with the Verta team to migrate to new permissions.
If your enterprise does not need any customization you’ll only need to be familiar with the general concepts in the Quick Start section.
Verta uses a customizable RBAC (role based access control) system to power our permissions. Below is a step by step walkthrough of our concepts, how they relate and how you can administer your own organization.
When we talk about a Verta Organization, what we mean is your company’s account in Verta. Most customers will only ever have one organization. Self hosted customers may choose to configure more than one organization but it will never be necessary to do.
Your organization must have at least one administrator, who has the ability to manage users, integrations and permissions. In the case of a self hosted install, your system administrator will also have the organization administrator role in the organizations. You may have as many organizations admins as you like.
Within your organization you (the organization admin) will have the ability to administrate users, groups, roles and workspaces. Each of these items is a separately configured component of the permissions system. Each of these features is managed on a separate tab on the organization admin page - our diagrams in purple show how the concepts relate. Screenshots from the tabs of the platform will be matched to the diagram.
You will begin with adding the correct users to your organization in the Verta platform. This will be a comprehensive list of all users, at all access levels - including virtual users like Service Accounts. You may choose to add the users using one of our authentication integrations, like Okta or Active Directory, so the user list stays in sync with your authentication platforms. You may add new users or remove existing ones at any time.
Here’s what that would like to you, the organization admin:
You can add users (or service accounts) using the primary action button at the top right. For either type of account, you will need to provide a user email which will act as the primary identifier of the user. As soon as you create a service account, it’s keys will be available to all organization admins.
Upon user creation you may edit the users display name and their membership in groups.
You can delete, edit or view user details from the actions column.
Groups are collections of users. Your Verta Organization will have some default groups available - all users, admins, etc. You may customize as many groups as you would like, or integrate your groups listing into your active directory system.
Here’s what the group listing looks like in your organization:
You may create new groups and edit existing groups (and their membership) from this page. The “Create New Group” button will open a dialog for you to create the group and add users in one batch.
You can reassess the group and edit the name, description or members from the action button at any time.
All users will be a member of the ‘All Users’ group, and your organization admins will be members of the “Admins” group. You may assign membership in groups to users individually or in batches using the groups or users admin UI. In our example you can see that four custom groups were added to divide our users into their roles in our organization. You may make any groupings you like.
For a single user you can see and edit their group members from the Users > Detail dialog.
Independent of your users and groups, your organization admins can configure access roles. Each role has a name and a set of actions members can take - like registering models, deploying endpoints, etc. Think of these as archetypes or reusable patterns of access levels. There are a few default roles (super users, regular users) but you may customize Verta to have as many roles as you see fit.
Each role has a name, a description and actions they may or may not take. Here’s what your Roles & Permissions tab might look like:
The two default roles are locked, but you may create, edit and delete custom roles as desired.
To create a new role, use the “Create New Role” button in the top right to open the role editing dialog:
Note - your Role will require a name and at least one permission to be saved. Any permission not explicitly granted is prohibited. Not all actions are available on all entity types (there is no way to deploy an endpoint, which by nature is already deployed) so the grid shows null values whereve an action is impossible.
You may edit your custom roles at any time by reassessing this dialog under the edit (pencil) icon on the actions column.
Your organization will have configurable workspaces. Workspaces are collections of entities in the platform - models, projects, endpoints, and so on. They are like directories or folders in which you store what you are working on. You can then “share” the folder with the right groups. You will have a default workspace as well the ability to create as many additional workspaces as you need.
Each workspace has its own Model Catalog which aggregates and organizes the entities in the workspace. For most customers, a single workspace is advised and you will not need to create additional workspaces. There will be an immutable default workspace for all customers for this reason.
The default workspace will be accessible to the All Users group. This is to enable quickly getting started with collaboration. You may edit the permissions to remove access to the all users group if needed.
You can create a new workspace using the “Create Workspace” button in the top right. Define the workspace with a name, and assign which people should have access (by group) at which editing level (by role).
When this all comes together, the system might look something like this:
In the above example, your organization has two workspaces - one default workspace for day to day work, and a custom “experimental” workspace for R&D projects. With custom groups and roles, access has been finely tuned. Beatriz, as a member of the User Experience group, has “regular user” role access to entities in the default workspace. In the R&D project, she’s a super user.
If you need help configuring your organization to fit your enterprises needs, please reach out to Verta and we will help you do this configuration.
You do not need to customize anything in the Verta Permissions system if your organization does not require it. Effectively everyone will collaborate on one model catalog and the models connected to it, but folks have different access based on the groups they are in.
Out of the box, you will have a default Admin and All Users group. Your designated organization admins will be in the Admins group. You will have two default roles and you can map these groups and roles as you see fit in the default workspaces. For many teams, this is the correct amount of controls.
- Governance Tools And Release Readiness Checklists
- If your organization wants to customize different release processes or checklists, you may assign one or more custom checklists to models by their workspace. To learn more take a look at the checklist documentation.
- Multiple Namespaces
- If your organization uses a multi-namespace setup with Kubernetes you will map Workspaces to Namespaces. See the namespace documentation for more information.
- Our suite of integrations, like setting a custom pypi library or configuring webhooks will soon happen at the organization level. For now, contact your sys admin to access these integrations.
If a user is in two groups that have different levels of access to the same workspace, they will receive the maximum possible access.
Users who don’t have permission to take an action will see the action/field/value but will not be able to set it or interact with it. We highly encourage you to give everyone read and edit permissions whenever it makes sense inside of a given workspace, so users aren’t blocked in their day to day jobs. Isolate models into different workspaces if you need clear division between teams.