📘 Catch up on the series:
And now, let’s dive into part three: How access control and permissions keep your multi-format repositories secure, consistent, and developer-friendly.
In the first two blogs of this series, we explored why repository structure matters and how Cloudsmith’s Hybrid Repository Structure balances control with flexibility. While we touched on policies and permissions, we didn’t dive into the real mechanics of how access control ensures artifact security, traceability, and consistency, especially in multi-format repositories, where different packages, languages, and tooling coexist in a single place.
While multi-format repositories allow for more flexibility in how your repositories are set up, they can introduce a new way of thinking about how and when different artifacts can be accessed and by whom. This blog breaks down how Cloudsmith provides fine-grained, flexible, and secure controls for teams of any size.
Cloudsmith provides the following user roles:
These roles help limit access based on organizational need and provide the foundation for more granular permissions.
You can explore the full breakdown of Cloudsmith roles, permissions, and privileges in our documentation.
You can read more about user roles, permissions, and privileges in Cloudsmith here.
Every Cloudsmith customer is given the opportunity to set default global privileges. These global default privileges are set for the “Member” user role in Cloudsmith, which is often suited best for individual developers. Within a customer’s global workspace privileges, organizations can choose to grant members the ability to create new teams, invite new users, and even create new repositories. Organization owners can also grant “blanket” repository privileges to all users within Cloudsmith.
While we offer the flexibility for organizations to shift responsibility and access to the developer, we often see our enterprise customers lean away from blanket permissions and access toward more fine-grained permissions. As an example, we have a semiconductor manufacturing customer that has disabled default workspace global privileges so that only Organisation owners are the only users who can invite new users, create new teams, invite 3rd-party collaborators, and create new repositories.
In addition, this customer has access control, and privileges are scoped down to specific teams. Default global repository privileges are disabled so that they can choose exactly which team(s) should have access to repository(s). Even Cloudsmith service accounts are grouped together within a team for ease of tracking permissions and access when it comes to build and deployment times.
If we zoom in once and look at the repository level in Cloudsmith, we can assign a default privilege for organization members for accessing packages within the repository, and we can assign specific privileges for specific teams, users, or service accounts.
This is the stage where you’ll have to consider what packages the repository is storing and if you want developers and service accounts to have default admin, read, or write permissions to the repository. Continuing to use my customer example, they have chosen to set default read permissions for all repositories; however, specific service accounts have write and admin permissions to different repositories. You may be okay with your developers downloading artifacts to their local machine for testing or even service accounts requesting stored artifacts tied to staging and production environments.
On the other hand, there are customers that may not want their developers having the ability to write to every repository and would most likely want specific service accounts tied to their CI/CD pipelines to only have write permissions. While this is generally best practice, there are certainly exceptions to this rule, as we also have platform teams that choose to grant specific developer teams write access to specific artifact repositories.
On top of the permission and access control settings we’ve discussed, Cloudsmith goes even further to ensure that, through various additional settings, platform teams can decide exactly what their developers need and don’t need to be reconfigured within a repository.
Platform teams are able to grant or deny developer permissions, such as:
If you thought that wasn’t enough, Cloudsmith takes it a step further by scoping down permissions to the individual developer’s generated packages. So while platform teams can restrict tampering of artifacts generated by other developers or systems, they can also decide if they would like to allow developers the ability to scan, move, copy, delete, or resync their own packages.
Most of the enterprise customers I work with allow developers to do as they please with their own packages to avoid a developer mutiny! In either case, these user actions are catalogued in our Audit Logs for enhanced observability across your Cloudsmith environment.
For instances where our customers want to be very particular about what, how, and when users can access specific packages, Cloudsmith offers Entitlement Tokens. These scoped tokens are read-access only, so there is never a risk of a user performing a write action against the repository they have limited access to.
Customers are able to restrict access by creating a precise search query to narrow down specific packages within a repository, should they choose not to provide visibility into all the packages within the repository. On top of visibility restrictions, customers can also add token usage restrictions to avoid prolonged access and usage of the token. Parameters include:
Typically, we see our customers use entitlements for 3rd party software distribution or even for systems that don’t require logins to Cloudsmith.
For our security-conscious customers, Cloudsmith also offers the ability to configure geo-based restrictions based on country, with an easy-to-use preconfigured list of countries to choose from. Choose to deny or allow access from specific countries. Although keep in mind that theoretically, no unauthenticated user should have access to your Cloudsmith workspace in general. This restriction applies more towards open-source repositories that you may be hosting in Cloudsmith, but it’s always a good idea to practice defence-in-depth!
If geo-based restrictions are too broad, you can scope down to IP-based restrictions to either allow or deny client access based on IP address. This added protection ensures that requests coming from clients with an unapproved IP address do not have access to your repositories.
With all of these configuration options, it can be tricky to decide how you want to best enable your developers while balancing security and flexibility. Not to worry—the Cloudsmith Customer Success team is here to help you in your decisions throughout the onboarding process. We’ve walked through these decisions with many customers and have outlined decision impacts for you so you’re not left wondering “what if”. Learn more about Cloudsmith here to get started with us. See you on the other side!
Access control defines who can read, write, or administer artifacts across different package formats stored in the same repository. It ensures secure, consistent governance across diverse tooling.
Cloudsmith supports global, repository-level, team-based, and user-specific permissions, allowing organizations to tailor access to packages, teams, service accounts, and even individual artifact actions.
Fine-grained controls reduce the blast radius of errors, prevent unauthorized writes, and help organizations enforce policies required by modern software supply chain frameworks like SLSA and SSDF.
Entitlement tokens provide scoped, read-only access to specific artifacts without requiring user accounts, making them ideal for external distribution, automation, or least-privilege workflows.
Yes. Cloudsmith allows permissions that let developers manage only the packages they personally created—without putting others’ artifacts at risk.
Service accounts can be granted precisely the permissions needed for pipeline operations (like write or admin) while keeping developers and collaborators restricted to read-only or scoped access.
Global privileges affect the entire workspace, while repository-level privileges enable granular control over specific teams, users, or service accounts interacting with a particular repository.
By submitting this form, you agree to our privacy policy
