Role Based Access Control

This feature is only available on Chainloop’s platform paid plans.

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:

Role	Org Access	Can Create Projects	Project-scoped RBAC
Organization Owner	Full Access	Yes	Admin on all projects
Organization Admin	Full Operations Access	Yes	Admin on all projects
Organization Viewer	Read-only	No	Viewer on all projects
Member	Limited	Yes (*)	Depends on project role
Contributor	Limited	No	Depends on project role

(*) Members become Project Admins on the projects they create

Org Owner, Admin and Viewer roles can operate on all projects in the organization. While Members and Contributors can only operate on projects they have been added to with a Project Role.

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.