Role Based Access Control

Chainloop Role Base Access Control (RBAC) allows scoping down users by resources (i.e. projects). For example, RBAC can be used to ensure that employees can only see and access the projects they are assigned to. Or to limit the actions that a particular user or group of users can perform on a Workflow (like sending an attestation). RBAC is implemented through Roles. Users can have assigned roles on organizations and projects for access control.

​

Roles

​

Organization roles

There are five organization level roles:

• Organization Owner: It’s the highest privilege role, providing full access to all resources and features. It’s the role acquired by the creator of the organization.
• Organization Admin: It’s a management role in the organization, they have full access to the organization, its members and projects.
• Organization Viewer: It’s a read-only role that provides full visibility on the organization resources.
• Member: Members can create projects. They only have permissions in projects they create, or they have been added to with a Project Role. Members can manage projects but cannot manage organization resources.
• Contributor: Contributors can only contribute to projects they have been added to with a Project Role. Contributors cannot create projects and cannot manage organization resources.

Organization access summary: (*) Members become Project Admins on the projects they create

​

Product roles

Product roles are used to manage user access at the product level, which is a collection of projects. There are two product roles:

• Product Admin: Provides full access to the product, including managing projects, attaching compliance frameworks, and managing user access.
• Product Viewer: Provides read-only access to the product and its associated projects.

Note that product roles will be propagated to the projects associated with the product, but they do not override project roles. For example, a Product Viewer will still have read-only access to the projects, but if they have a Project Admin role on a specific project, they will have full access to that project.

​

Project roles

Project roles are needed when the user has the Organization “Member” or “Contributor” role to define their access level to specific projects. There are two different project roles:

• Project Admin: Provides full access to the project resources. For example, they can manage workflows, create project-scoped contracts, configure compliance frameworks, and user or group membership. They can also create project API tokens and perform attestations.
• Project Viewer: Provides read-only access to the project, workflows, and attestations.

​

Assigning product and project roles

You can list and manage members through products or project settings: Then you can use the membership form to add members and assign them project roles: Propagated roles will be shown grayed out, indicating that they are inherited from the product level.

​

Groups

Groups can help in organizing users by Business Unit, Teams, Department, or any other criteria. They can be attached to projects with a given role. Users of the group would acquire that role when accessing the project.

​

Creating groups

Only Organization Admins can create groups through the “Groups” section in Organization settings:

​

Adding users to a group

In Group Details view, Admins can add new members to an existing group by clicking the “Add Member” button: Group “Maintainers” can add and remove members from the group, regardless of their Organization Role.

​

Project-scoped API tokens

Alongside org-level API tokens, project-scoped API tokens can now be created from the project settings: These tokens can be used to authenticate the Chainloop CLI/API, perform attestations, or operate in the context of a specific project. This adds security guarantees that a team can’t interfere with another team’s project and removes the bottleneck of requiring an organization administrator to provide such tokens.

​

Summary of RBAC permissions

Here you can find a summary of all the permissions (Read, Read/Write) associated with each role and resource.

​

Org-level resources

​

Product/project level resources

(1) API tokens cannot be “read” since they are only available at creation time. But they can be listed. (2) Product Admins become Project Admins in the projects associated with the product. So any project-scoped permission that requires Project Admin role, is also available to the Product Admin in the parent product. (3) Depending on the configuration, new organizations could be created by any user, or by an instance-level “Instance admin” role (4) Memberships are managed by org admins and owners. But any user can leave an organization at any point (5) Group membership can ba also managed by “Group Maintainers” (6) API tokens can create contracts only during the attestation process