Example RBAC Setup
Context
The following describes an example of a typical RBAC setup for a Data Mesh landscape, complete with roles, example groups and scopes for the permissions. It should be seen as an example, and you will need to adapt it based on your organization's structure, processes and data landscape.
It assumes that there are three environments in which Data Products can be deployed:
- Production: identified as
prd - Quality Assurance: identified as
qa - Development: identified as
dev
as well as two domains:
- Sales: identified as
urn:dmb:dmn:sales - Marketing: identified as
urn:dmb:dmn:marketing
Roles and permissions
We are going to use typical roles for a Data Mesh-based data platform, namely these five:
- Administrator: has every permission including modifying platform settings; not intended for everyday users but only highly privileged personnel
- Data Product Owner: owns Data Products and can manage all their lifecycle, including creating new major versions and deploying to production
- Data Product Developer: develops Data Products and can manage all their lifecycle, excluding creating new major versions and deploying to production
- Governance: manages platform governance settings like policies and documents
- Read Only: can only view objects, cannot make any changes to anything
The following table summarizes the permissions for the roles:
| Permission | Administrator | Read Only | DP Owner | DP Developer | Governance |
|---|---|---|---|---|---|
| practice-shaper.edit | X | ||||
| practice-shaper.import | X | ||||
| catalog.entity.read | X | X | X | X | X |
| catalog.entity.create | X | X | X | ||
| catalog.entity.delete | X | X | X | ||
| catalog.entity.refresh | X | X | X | ||
| catalog.location.read | X | X | X | X | X |
| catalog.location.create | X | X | X | ||
| catalog.location.delete | X | X | X | ||
| catalog.platform.create | X | ||||
| catalog.platform.delete | X | ||||
| catalog.platform.refresh | X | ||||
| builder.software-catalog.view | X | X | X | X | |
| builder.dp.snapshot.create | X | X | X | ||
| builder.dp.release | X | X | X | ||
| builder.dp.deploy.prd | X | X | |||
| builder.dp.deploy.qa | X | X | X | ||
| builder.dp.deploy.dev | X | X | X | ||
| builder.dp.newversion | X | X | |||
| builder.dp.commit | X | X | X | ||
| builder.dp.policies.test | X | X | X | X | |
| builder.system-prototype.edit | X | ||||
| cgp.entity.view | X | X | X | X | X |
| cgp.entity.edit | X | X | |||
| documents.document.insert | X | X | |||
| platform.settings.edit | X | ||||
| platform.custom-view.edit | X |
Groups
Users are assigned to different groups, which are granted specific roles.
The groups and the assigned roles are:
WITBOOST_ADMINS: highly privileged users, like the Platform Team; assigned the "Administrator" role.WITBOOST_USERS: generic users; assigned the "Read Only" role.WITBOOST_DP_OWNERS: users that own or will own Data Products; assigned the corresponding role.WITBOOST_DP_DEVELOPERS_<DOMAIN>: users that develop or will develop Data Products for a specific domain; assigned the corresponding role and scoped to the proper domain.WITBOOST_GOVERNANCE: Governance Team users.
This example setup defines the baseline for the default preset for automatic RBAC configuration.
With this setup, developers are scoped to their specific domain, while other kinds of users have the same permissions on all the domains.