Using Ansible to deploy packages from Cloudsmith

A quick example of building an Ansible playbook to deploy a package from a private Cloudsmith repository.

Using Buildkite to push packages to Cloudsmith

Dan McKinney, DevRel at Cloudsmith, takes a look at how to set up a Buildkite pipeline to push packages to Cloudsmith.

One reason for building a ‘single source of truth’ for 

 is that it gives the organization control over who can use what when.

The ‘wild West’ of public repositories gives no control at all and can lead to a situation in which packages and dependencies of dubious provenance are integrated into builds without a second thought. Within the Cloudsmith world, we want to have the maximum security and control possible.

Permissions can also help the individuals and teams in the organization find what they need faster, by ensuring that the repositories they see are optimized for them alone.

To help make that happen, Cloudsmith includes the ability to create teams and organizations and limit access to repositories at team and individual level. Let’s take a look in more detail about how to make that happen, and discuss other considerations when building out teams and orgs.

It all starts with the organization. Organizations give you the ability to configure access for teams, individuals and machines that map to your companies organizational structure - and building security and resilience into the management of teams and workflows is essential in today's ecosystem.

We recommend creating only one organization in Cloudsmith. You are not limited to one, but as we allow as many teams as you like beneath any organization, there isn’t really a need to create more. Similarly, as all teams and users are associated with a specific organization, more than one of the latter will usually mean replication of effort.

As a further consideration, a single organization helps in terms of transparency as reporting, auditing etc is also delivered at the organization level.

full details are in our documentation here

). Once that is done, you can configure name, billing and contact details and so on before considering global permissions.

At the organization level Cloudsmith allows users to define global privileges for members around inviting new collaborators and members, and creating teams and repositories. In the same way object privileges can be set - that determine the access level members have in terms of access and actions for repositories within that organization.

Similarly, at an organization level you can define usage limits for repositories and check what the current situation is around usage at any time - handy for managing or avoiding unpredictable usage bills.

In order to manage permissions and access at a more granular level, you will want to create teams within organizations. Cloudsmith then enables permissions for teams to be managed at the repository level.

When creating teams, think clearly about 

 between groups within your organization when it comes to package management. You may want to limit publishing packages to repositories (write access) to specific teams, which limiting others to read access, for example.

To put that another way, when giving any team access to a repo, you will be asked to specify the level of access for that team (as shown in the image below), so it makes sense to build out teams with that in mind.

Although teams can help manage permissions quickly and transparently, it is of course also possible to give named individual users access to individual repositories, and specify what level of access they have - in this way individuals not in teams can be given access, and those already in teams can be given improved access over that offered to the team as a whole.

ultimately permissions are controlled at the repository level

. When creating a repository (or indeed at any time after) Cloudsmith enables you to specify precisely what ‘Admin’, ‘Write’ and ‘Read’ access will enable each user or team to perform, and this is specified at the repository level as shown in Figure 2.

This effectively means that a single team (or individual) can have ‘Write’ access to separate repositories that means something slightly different in each case. Ideal for fine-grained control. Cloudsmith is all about securing your software assets. Our platform gives the control to do that. Remember - err on the side of caution!

If you haven't already, try out these features through a free trial of Cloudsmith today. Get started with your first repository within 60 seconds!

Creating Organizations and Teams and Managing Permissions In Cloudsmith

What software assets does your organization use?

What sounds like a simple question is anything but. If we include every package and dependency that ends up in the code we produce then for most development teams the truthful answer is ‘we don’t know’.

As we’ve said enough times already, that really isn’t good enough anymore. And that’s one of the core motivations behind Cloudsmith. A central private repository provides an ‘isolation layer’ in which everything you use is both stored and controlled.

Cloudsmith is entirely flexible in terms of how repositories are built and structured. Depending on what is convenient for your organization, you can either build universal repositories in which packages in multiple formats sit side-by-side, or format specific repositories.

But our support for transparency around the use of software assets across the entire organization doesn’t stop there.

By providing a single repository for all your assets, Cloudsmith enables you to check at a glance exactly which individuals and processes are downloading those assets. This can be helpful in a number of ways. It certainly is if you need to quickly establish precisely where any given package may have been used in the wake of identifying a specific vulnerability.

Download logs in Cloudsmith, as shown below, mean you have a record of precisely what is being used where, and by who or what. At any moment you have a full audit trail and detailed information relating to every download of every asset, so you can ensure the right people are accessing the right things in the right way.

We also provide event logs along similar lines, so you can keep a handle of any actions against any package within your Cloudsmith environment.

Beyond granular level access logs, Cloudsmith also supports aggregated reporting around access to each individual repository. This includes download and upload counts and associated bandwidth, plus downloads and uploads reported against geolocation, package type and distribution.

This type of reporting has a variety of uses. For one, it helps manage your account with Cloudsmith and ensure total visibility around usage, which in turn can be used to accurately forecast costs. (Cloudsmith also supports the configuration of retention/lifetime rules, meaning you can automatically delete or move packages after a certain amount of time in order to actively control those costs).

Full statistical reporting also provides key insight around which packages and formats are most popular, plus which are trending up or down in terms of usage. This data in turn can help understand where the business is particularly exposed to one package or package type, or alternatively which packages are being stored and rarely used.

All in, we provide a variety of methods for understanding how your repositories, packages and assets are used. All of them support better, more efficient development and distribution.

Auditing and Reporting In Cloudsmith

Using AWS CodeBuild to push packages to Cloudsmith

Dan walks through how to configure AWS CodeBuild to push packages to Cloudsmith.

For Vendors: No-code software distribution using Zapier and Cloudsmith

A walkthrough of how to use the Cloudsmith Zapier integration to connect your payment platform or provider to your Cloudsmith private repositories and power your Global software distribution needs.

Getting Started with Conan and Cloudsmith

A quick walkthrough of getting set up with Conan (C / C++) and Cloudsmith, including uploading and downloading packages using the native Conan tooling.