Repositories

Per-repository privileges

There are three different repository settings defining user access to artifacts and repository settings:

• Repository Privileges: Defines the minimum level of privilege required for a user to perform specific actions. This setting is overridden by User/Self privileges when the user is the owner of a package.
• Self Privileges: Defines which actions users can always do with their own packages, no matter what are the privileges defined at other privilege levels (workspace, repository, team).
• Access control: Defines the default level of privilege assigned to all workspace members (no collaborators) for this repository.

Before we dig deeper into each of them, here we can find the different levels of access that you can assign to users, services and members of teams in a repository:

Fine-tuning Privileges

Note that this privileges can be fine tuned per action (see Repository privileges).

Public repositories

Public repositories are open by definition, hence there's no level of privileges or belonging to the workspace required to have read access to its assets.

Repository privileges

With these options, you can define the minimum level of privileges granted required to perform certain actions within a repository:

Self privileges

With this option, we can define which of the following actions can always be performed by users with their own packages, no matter which other permissions are stablised per workspace, repository, team, or user:

• Scan
• Copy
• Move
• Delete
• Resync

Additionally, we can enable/disable user entitlements for a private repository. This setting allows users to use and manage their own entitlement token for the repository.

Access control

Access Controls allows you to configure the default level of privilege assigned to all workspace members (no collaborators) for this repository:

• Admin
• Write
• Read
• None

Privileges for specific users, services and teams

Additionally, you can increase the level of repository privileges for specific:

• Users
• Services
• Teams

Manage explicit access with the CLI

Use cloudsmith repos privileges to inspect or change privileges granted directly to teams, users, and service accounts. These commands require permission to manage the repository's privileges, and they act on explicit repository grants only. Default workspace privileges and privileges inherited through team membership still contribute to an account's effective privilege.

In the following examples, WORKSPACE is your workspace slug and REPOSITORY is your repository slug. The CLI help shows these as OWNER/REPO.

List explicit privileges

cloudsmith repos privileges list WORKSPACE/REPOSITORY

The output identifies each target as a team, user, or service account and shows its Read, Write, or Admin privilege. For machine-readable output, add -F json after the subcommand, for example cloudsmith repos privileges list WORKSPACE/REPOSITORY -F json. ls and get are aliases for list.

Grant or change privileges

Use set to add or update any number of targets without changing other explicit grants:

cloudsmith repos privileges set WORKSPACE/REPOSITORY \
  --team developers \
  --user octavia \
  --service release-automation \
  --privilege write

The same privilege applies to every target in the command. Each --team, --user, or --service value is the corresponding team, user, or service account slug. Repeat an option to include more targets. Accepted privilege values are read, write, and admin.

Before lowering a target's existing privilege, set asks for confirmation. Granting or raising a privilege never asks. Pass --yes to skip both the check and the confirmation.

Revoke explicit privileges

cloudsmith repos privileges revoke WORKSPACE/REPOSITORY \
  --user octavia \
  --service release-automation

The CLI asks for confirmation before writing, and targets without an explicit grant are named and skipped. Pass --yes to skip the confirmation. revoke rewrites the full list of explicit privileges, so a change made by someone else at the same time can be lost.

Replace all explicit privileges

Use replace when a JSON file should be the complete source of truth:

{
  "privileges": [
    { "team": "developers", "privilege": "write" },
    { "user": "octavia", "privilege": "read" },
    { "service": "release-automation", "privilege": "admin" }
  ]
}

Apply the file:

cloudsmith repos privileges replace WORKSPACE/REPOSITORY privileges.json

The file can also contain the array directly, without the top-level privileges property. Each entry must contain exactly one of team, user, or service, and duplicate targets are rejected.

'replace' removes omitted grants

replace revokes every explicit privilege that is not in the file, including your own. An empty array revokes all explicit access to the repository. Accounts can retain access through a default workspace or repository privilege, or through an explicit grant to one of their teams.

The CLI asks for confirmation before replacing privileges. To read JSON from standard input, use - as the file name and pass --yes because the same input stream cannot also answer the confirmation:

cat privileges.json | cloudsmith repos privileges replace \
  WORKSPACE/REPOSITORY - --yes

Effective privilege

The effective privilege for an account (User or Service) is the greatest privilege granted to them via:

• Assignment to them directly, via Privileges for Specific Users/Services.
• Derived from their team membership via Privileges for Specific Teams.
• By default on the repository, via Default Privileges.
• By default on the workspace, via the org-wide "Default Object Privileges" (see Workspace Settings.

When granting a Team or User access to a repository, you can select from the following privilege levels.

External user access

To allow external (non-Cloudsmith) users access to a private repository, please see our Entitlement Tokens documentation.

Updated 1 hour ago