Skip to main content
Mistrive uses a hierarchical permission model where access flows down from organizations to projects to individual resources. Understanding this hierarchy helps you grant appropriate access without over-permissioning.

​
Resource hierarchy

Resources are organized in a tree structure: 
Global System
└── Organization
    └── Project
        ├── Service Account
        └── Repository
Permissions granted at a higher level automatically apply to resources below. A user with Editor access to an organization has Editor access to every project in that organization.

​
Role inheritance

Within each resource type, roles inherit from more privileged to less privileged: 
Owner → Editor → Viewer → Member
Granting Owner automatically includes Editor, Viewer, and Member permissions. You never need to assign multiple roles to the same principal on the same resource.

​
How permissions flow

​
Organization to project

Organization roleProject access
OwnerOwner on all projects
EditorEditor on all projects
ViewerViewer on all projects
MemberNo automatic project access
The Member role is unique—it grants organization membership without any inherited project access. Use it when you want to manually control access to each project.

​
Project to repository

Project roleRepository access
OwnerOwner on all repositories
EditorEditor on all repositories
ViewerViewer on all repositories
Additionally, Artifact Store-specific roles provide scoped access:
Project roleRepository access
Artifact Store OwnerOwner on all repositories
Artifact Store EditorEditor on all repositories
Artifact Store ViewerViewer on all repositories
These roles let you grant registry access without broader project permissions. A CI service account that only needs to push images can receive Artifact Store Editor without access to other project resources.

​
Artifact Store permissions

The Artifact Store adds a parallel set of roles that flow through the hierarchy specifically for registry access.

​
At the organization level

Organization roleEffect
Artifact Store OwnerOwner on all repositories in all projects
Artifact Store EditorEditor on all repositories in all projects
Artifact Store ViewerViewer on all repositories in all projects

​
At the project level

Project roleEffect
Artifact Store OwnerOwner on all repositories in the project
Artifact Store EditorEditor on all repositories in the project
Artifact Store ViewerViewer on all repositories in the project

​
At the repository level

Repository roleCapabilities
OwnerManage permissions, delete repository, push and pull
EditorPush and pull images
ViewerPull images only

​
Combined inheritance

Permissions combine from all levels. A principal’s effective access is the union of:
  1. Roles directly assigned on the repository
  2. Artifact Store roles on the parent project
  3. General roles on the parent project (which include Artifact Store access)
  4. Artifact Store roles on the parent organization
  5. General roles on the parent organization
For example, if a user has Artifact Store Editor on the organization, they can push to any repository in any project within that organization—regardless of project-level or repository-level assignments.

​
Special principals

Repositories support two special principals for public access scenarios:
PrincipalWho it includes
allUsersEveryone, including unauthenticated requests
allAuthenticatedUsersAny user logged into your Mistrive instance
These principals can only be assigned the Viewer role, ensuring public repositories remain read-only.

​
Global administrators

Global administrators bypass the normal permission hierarchy. They have full access to:
  • Create and manage organizations
  • Create and manage users
  • Access all projects and repositories
  • Modify any IAM settings
Global administrator status is managed separately from the role hierarchy. See Initial setup for creating the first administrator.

​
Common patterns

​
Centralized team with project isolation

Assign users as organization Members, then grant project-specific roles:
  • Team A: Artifact Store Editor on Project A
  • Team B: Artifact Store Editor on Project B
Each team can only push to their designated project.

​
Read-only access for stakeholders

Grant organization Viewer role to stakeholders who need to browse but not modify resources. They can view all projects and pull images but cannot push or change settings.

​
CI/CD service accounts

Create service accounts per project with Artifact Store Editor role. This provides push access to all repositories in the project without granting broader permissions.

​
Public image distribution

Add allUsers as Viewer on specific repositories intended for public consumption. Anyone can pull these images without authentication.