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

Instance role

The Instance Admin role is only available in Enterprise Edition self-hosted (on-prem) deployments.

Instance Admin is an instance-wide role that sits above organizations. It is not assigned from the UI: instance admins are declared in the deployment configuration through auto-onboarding, either with a static allowlist of emails and domains (instance_admin_spec) or with SSO claims that map the reserved instance organization to the admin role.

Instance admins can:

• Create organizations, even when organization creation is restricted in the control plane.
• Invite members to any organization in the instance.
• List and create CAS backends in any organization.
• Create, list, and revoke instance-level API tokens, which carry the same instance-wide permissions. See Organization provisioning with API tokens.

The role is limited to those operations, and the boundary holds in both directions:

• Being an instance admin does not grant access to organization content. When an instance admin operates on an organization where they hold no membership, the permissions above are all they get: reading projects, workflows, or attestations still requires an organization, product, or project role.
• Instance-level operations are reserved for instance admins. Organization Owners and Admins cannot perform them, despite having full access within their own organization.

On Chainloop-managed (SaaS) instances, the Instance Admin role is held only by Chainloop operators, who use it for instance administration tasks such as billing account and identity provider management.

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.

Summary of RBAC permissions

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

Instance-level resources

These resources are only available to the Instance Admin role and to instance-level API tokens. They are not available to any organization, product, or project role.

Resource	Instance Admin	Instance API tokens (7)
Storage backend	RW (8)	RW (8)
Instance API tokens	RW	RW
Organizations	RW (9)	RW (9)
Organization invitations	RW	RW

Org-level resources

Resource	Org Admin / Owner	Org Viewer	Org Member	Org Contributor	API tokens
API tokens	RW	R (1)
Artifact	RW	R	RW	RW
Audit logs	R
Business Units	RW	R	R	R
Contracts	RW	R	R	R	RW (6)
Frameworks	RW	R	R	R
Integrations	RW	R	R	R
Memberships (4)	RW	R	R	R
Org settings	RW	R	R	R
Organization	RW (3)	R	R	R
Policies	RW	R	R	R
Requirements	RW	R	R	R
Repositories	RW	R	R	R
Signing certificate	R	R	R	R	R
Storage backend	RW	R	R	R
User group	RW (5)	R	R	R

Product/project level resources

Resource	Org Admin / Owner	Org Viewer	Org Member	Org Contributor	Product Admin	Product Viewer	Project Admin (2)	Project Viewer	API tokens
Attestation	RW	R					RW	R	RW
Comments	RW	RW			RW	RW	RW	RW
Compliance Data	RW	R			RW	R	RW	R	R
Contracts	RW	R					RW	R	RW (6)
Discover (graph)	R	R					R	R
Evidence	R	R			R	R	R	R	R
Files	RW						RW
Integration attachments	RW	R			RW		RW
Products	RW	R			RW	R			R
Projects	RW	R					RW	R	RW
Workflow Metrics	R	R					R	R
Workflow Run	RW	R					RW	R
Workflows	RW	R					RW	R	RW (6)

(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 only by the 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 (7) Instance-level API tokens are created by instance admins with chainloop admin api-token create and carry the same instance-wide permissions (8) Instance admins can list and create storage (CAS) backends in any organization. Updating or deleting an existing backend is an Org Admin operation in the organization that owns it (9) Creation of new organizations. Deleting an organization remains reserved to its Org Owners