> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mistrive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions

> Understand how roles and permissions flow through the hierarchy

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 role | Project access              |
| ----------------- | --------------------------- |
| Owner             | Owner on all projects       |
| Editor            | Editor on all projects      |
| Viewer            | Viewer on all projects      |
| Member            | No 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 role | Repository access          |
| ------------ | -------------------------- |
| Owner        | Owner on all repositories  |
| Editor       | Editor on all repositories |
| Viewer       | Viewer on all repositories |

Additionally, Artifact Store-specific roles provide scoped access:

| Project role          | Repository access          |
| --------------------- | -------------------------- |
| Artifact Store Owner  | Owner on all repositories  |
| Artifact Store Editor | Editor on all repositories |
| Artifact Store Viewer | Viewer 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 role     | Effect                                     |
| --------------------- | ------------------------------------------ |
| Artifact Store Owner  | Owner on all repositories in all projects  |
| Artifact Store Editor | Editor on all repositories in all projects |
| Artifact Store Viewer | Viewer on all repositories in all projects |

### At the project level

| Project role          | Effect                                    |
| --------------------- | ----------------------------------------- |
| Artifact Store Owner  | Owner on all repositories in the project  |
| Artifact Store Editor | Editor on all repositories in the project |
| Artifact Store Viewer | Viewer on all repositories in the project |

### At the repository level

| Repository role | Capabilities                                         |
| --------------- | ---------------------------------------------------- |
| Owner           | Manage permissions, delete repository, push and pull |
| Editor          | Push and pull images                                 |
| Viewer          | Pull 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:

| Principal               | Who it includes                              |
| ----------------------- | -------------------------------------------- |
| `allUsers`              | Everyone, including unauthenticated requests |
| `allAuthenticatedUsers` | Any 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](/user-guides/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.