Roles and grants
A role is a named set of repository permissions. A grant gives one role to a Team or a member on a set of repositories:
who + role + where = grantFor example:
Release Engineering + Publisher + every repository in paymentsAlex + Maintainer + payments/apiBuilt-in roles
Section titled “Built-in roles”Each role includes everything in the roles above it.
| Role | What it adds |
|---|---|
| Reader | Download packages and view repository details. |
| Publisher | Publish packages, push container images and Helm charts, and add container image tags. |
| Maintainer | Delete and yank versions, delete packages, restore deleted content from the trash, remove container image tags, manage upstreams, connected mirrors, and package resolution rules, manage Package Protection, grant access to the repository, and view repository usage. |
| Admin | Change repository settings, such as its name and package formats, and delete the repository. |
A Maintainer can grant Reader, Publisher, or Maintainer on repositories they maintain, but never Admin, and cannot change or remove a grant above their own level.
Repository roles do not make anyone an organization or namespace administrator. Even Admin does not include organization membership, billing, storage, Teams, or private-mirror management.
Custom roles
Section titled “Custom roles”When a workflow needs a different combination of permissions, an organization administrator can create a custom role:
- Open organization settings and select Access.
- Under Advanced, select Roles.
- Select New custom role, name it, choose its permissions, and create it.
Every custom role includes Reader permissions, so it can always see the repositories it applies to. Custom roles belong to the organization and can be granted in any namespace. Editing a custom role changes every grant that uses it, so Ravenstash shows the effect before saving.
Where a grant applies
Section titled “Where a grant applies”| Where | Applies to | Who can receive it |
|---|---|---|
| Every repository in the organization | Every current and future repository in every namespace | Organization Teams attached to every namespace |
| Every repository in a namespace | Every current and future repository in that namespace | Attached organization Teams, the namespace’s Teams, and namespace members |
| Specific repositories | Only the repositories you choose | Attached organization Teams, the namespace’s Teams, and namespace members |
Grants follow membership:
- A member can receive a grant only in a namespace they belong to. If they are not a member yet, Grant access offers Add to namespace and grant.
- An organization Team can receive a grant only in namespaces it is attached to.
- Individual members cannot receive organization-wide grants. Use an organization Team, or the namespace base permission, instead.
When a member leaves a namespace, or a Team is detached from it or archived, the grants that depended on that relationship are removed.
Grant access
Section titled “Grant access”Every access page uses the same Grant access dialog: choose who, the role, and where. Ravenstash shows how many repositories the grant covers before you confirm.
| Start from | Use it to grant |
|---|---|
| Organization Access → Organization-wide grants | An organization Team a role on every repository |
| Namespace Access | A Team or member a role on every repository in the namespace |
| Team Repositories | This Team a role on a namespace or on specific repositories |
| Member Access | This member a direct role on a namespace or on specific repositories |
| Repository Access | A Team or member a role on this repository |
Organization administrators can grant anywhere. Namespace administrators can grant inside the namespaces they administer. Maintainers and Admins of a repository can grant access on that repository.
Access is additive
Section titled “Access is additive”Ravenstash combines every applicable role. There are no deny rules.
Suppose every member of payments has the Reader base permission and the
Release Team has Publisher. A Release Team member can publish. Giving that
person Reader directly does not reduce their access.
Removing one grant may leave the same access in place through the base permission, another Team, or administration. When you remove a grant, Ravenstash shows what the person or Team keeps. See base and effective access.