Behind the scenes of Team Roles

Team Roles can be configured in the Practice Shaper by modelling the relationship between a System Type and RBAC roles.

This is an example configuration:

apiVersion: witboost.com/v2
kind: SystemType
metadata:
  name: dataproduct
  displayName: Data Product
  description: A data product is a set of data and related assets that are designed, developed, and managed to provide specific value to its users. It is treated as a product with its own lifecycle, from inception and development to deployment and maintenance
spec:
  resourceTypeId: dataproduct
  belongsTo: taxonomy:default/data-mesh-taxonomy
  partOfDomain: domaintype:default/business-domain
  property: value
  isOwnedBy:
    assigneeRbacRole: DP_OWNER
    limitedAssigneeRbacRole: DP_OWNER_LIMITED
  dataAccessGrantedBy:
    assigneeRbacRole: DP_DATA_ACCESS_MANAGER

What we are declaring here is that:

• All Data Products in Witboost (i.e. instances of the Data Product System Type) can now manage Team Roles. Hence, you are enabling the Team Roles panel for Data Product owners.
• The user who is assigned to the Owner team role will be granted the DP_OWNER RBAC role with project scope
• The user who is assigned as Limited Owner team role will be granted the DP_OWNER_LIMITED RBAC role with project scope
• The user who is assigned to the Data Access Manager team role will be granted the DP_DATA_ACCESS_MANAGER RBAC role with project scope
• The Data Access Manager team role cannot have limited assignees i.e. Project Owners cannot assign users in limited mode in the Team Roles panel.

The RBAC roles themselves are not enough, because every Team Role full assignee or limited assignee is determined by the presence of a specific permission. This will be clearer in the next section.

How Witboost determines who holds a Team Role

When Witboost needs to know “who is the owner of project X?” (or e.g. the Data Access Manager), it follows a resolution process.

To understand this properly, you first need to understand how assignment works, because the two mechanisms are not symmetrical: a team role is assigned via an RBAC role, but who fills that role is resolved by searching for a specific RBAC permission.

• When assigning a team role to a subject, Witboost grants them an RBAC role (e.g., DP_OWNER) with a specific scope (e.g., project X). The RBAC role granted is the one configured in the example YAML above.
• When resolving who holds a team role, Witboost does not look for said RBAC role but instead looks for who possesses a specific RBAC permission (e.g., control-plane.project.team-roles.manage) for that project.

In other words: the RBAC role is the vehicle through which the permission is granted, but it is the permission that determines who is the Owner (or any other Team Role). This means that, when configuring Team Roles as you will see later, if the RBAC role DP_OWNER does not contain the permission control-plane.project.team-roles.manage, the user will NOT appear as Owner even if they have the role.

Available Team Roles

As of now, Witboost defines 2 team roles that can be enabled on your instance:

Team Role	Practice Shaper Relation	Full Assignee RBAC Permission	Limited Assignee RBAC Permission
Owner	isOwnedBy	control-plane.project.team-roles.manage	control-plane.project.team-roles.limited-manage
Data Access Manager	dataAccessGrantedBy	control-plane.project.manage-access	control-plane.project.limited-manage-access

These 2 roles are not extensible. What the platform team configures is which of these roles are active for each SystemType and how they map to specific RBAC roles.

Each Team Role comes with:

• A full assignee RBAC permission (identifies who holds the role as full assignee)
• A limited assignee RBAC permission (identifies who holds the role as limited assignee)
• A Practice Shaper relation (the field in the SystemType's spec)

Then when you assign someone to a Team Role from the Team Roles panel, Witboost grants them the RBAC role configured in the SystemType with the scope of that project. This way, when someone is assigned as, for example, Owner for a project, they get the DP_OWNER RBAC role with scope of that project, which contains the control-plane.project.team-roles.manage permission that makes them appear as Owner when Witboost determines who is the Owner for that project (known as the Resolution process, as explained below).

How Resolution Works, Step by Step

Let's take an example: "Who is the Owner of project urn:dmb:dp:finance:sales-report:0?"

1. Witboost identifies the SystemType of the project (e.g., dataproduct) via Practice Shaper
2. Reads the configuration of the Owner team role from the SystemType (isOwnedBy field). If not present, the role is not configured for that project type
3. Queries the RBAC system: retrieves all subjects that have the permission control-plane.project.team-roles.manage with a scope that includes urn:dmb:dp:finance:sales-report:0
4. Separately, also queries for limited assignees: retrieves all subjects that have the permission control-plane.project.team-roles.limited-manage with a scope that includes the same URN
5. Filters and sorts the results

What happens if no one is assigned (Fallback)

If the RBAC resolution finds no subjects, Witboost activates a fallback mechanism:

For the Owner role:

Witboost looks at the catalog's legacy field (spec.mesh.projectOwner, spec.mesh.dataProductOwner, or spec.owner) and returns that subject as a fallback Owner. This value comes from the project's catalog-info.yaml and represents the ownership declared before Team Roles was introduced.

For other roles (e.g. Data Access Manager):

If no Data Access Manager is found, Witboost performs a recursive fallback: it resolves the project's Owner and returns them as the default responsible. The logic is: if no one has been explicitly nominated for that role, the responsibility falls back to the Owner.

What if Team Roles is disabled (Retrocompatibility)

When Team Roles is disabled or a project has not been onboarded, the legacy behavior of Witboost is kept:

Access Control requests go to the project owner, which will correspond to the user that appears in the projectOwner or dataProductOwner field in the deployed descriptor i.e. the last successfully deployed version of a project.

Security Aspects and Considerations

1. RBAC is source of truth

Team Roles is not a standalone security system. It is an interface to RBAC. If a user has the RBAC role PROJECT_OWNER assigned directly in the RBAC system (bypassing Team Roles), they will still appear as the project's Owner. Team Roles is a facilitator for Data Teams, not a gate.

2. SystemType Configuration is critical

If the platform team configures assigneeRbacRole: "ADMIN" in the SystemType, anyone assigned as Owner for that project type will receive the ADMIN RBAC role with all its permissions with project scope. The mapping between team role and RBAC role determines the actual privilege level.

3. Team Roles gives Data Teams the ability to self-assign the configured RBAC roles

Even if users won't have the RBAC permission to edit RBAC assignments, through Team Roles, they will be able to make such assignments. This is achieved with the On-Behalf Of mechanism, i.e. Witboost makes RBAC assignments on behalf of the user if user have control-plane.project.team-roles.manage or control-plane.project.team-roles.limited-manage.

However, from the Team Roles panel users won't be able to make an RBAC role assignment with a scope broader than the project itself (e.g. urn:dmb:dp:finance:project-x:0).

4. Onboarding mechanism

If a project does not yet have an Owner assigned via RBAC, the system allows the catalog-info-owner (the legacy owner declared in the YAML in the fields projectOwner or dataProductOwner) to self-assign as Owner. This is the onboarding mechanism for migration. Once an Owner has been assigned via RBAC, the catalog-info fallback is no longer able to manage Team Roles.

5. Troubleshoot Permission

There is a special permission control-plane.project.team-roles.troubleshoot that authorizes all actions on all team role assignments. It should be assigned only to admins/platform team because it gives access to every projects team roles panel.