Exploring new capabilities in the Chainguard Registry to enable secure and efficient container image management

Having the most secure foundation to deliver our Chainguard Images product is critical and it's why we’ve taken a novel and security-first approach to building our Chainguard Registry. To date, our Chainguard Registry has been used to host images created and managed by Chainguard. We’ve heard regular feedback from the community, and our existing Chainguard Images customers, that having the option to upload and host their images in the Chainguard Registry would add value for their container security management strategy. To better understand what this new service and its capabilities should look like, we want to partner with users who would be willing to provide feedback as we evolve the product. Continue reading to learn more about the features and capabilities we’re considering. If you are interested in being a design partner or an early tester for the Chainguard Registry, fill out this form.

‍

Why build our own registry?

‍

Our team at Chainguard has years of collective experience building enterprise-grade container registries at previous companies. As we started on this journey, we found that existing solutions did not fulfill our requirements for a secure-by-default registry solution. In May, we published a post that shared more about our decision to build our own registry, and several of the design choices we made. A few of the features that we’re really proud of, and that piqued the interest of others, include:

‍

• Cost and scale:

  Cost was a major consideration for us when setting out to build the Chainguard Registry. We maintain an entire collection of public Chainguard Images at no cost to users. In order to scale, and add more images for years to come, we needed to find a more economical, reliable and scalable solution. We built our Chainguard Registry on Cloudflare R2 to distribute images to our users. This allows us to minimize egress costs and take advantage of Cloudflare’s CDN. Ultimately, this intentional approach lets us pass savings on to customers, without resorting to rate limits.

• Passwordless authentication:

  The Chainguard Registry relies solely on short-lived OIDC tokens to push and pull images. Internally, the way we take advantage of this in our own image build pipelines is by only authorizing our GitHub Actions workflow identity to push to it. This means that no Chainguard employee has direct access to push to the registry. Another benefit of passwordless authentication for the Chainguard Registry is that it makes it less likely that malicious third parties can tamper with registry contents. One more link in the software supply chain hardened. ✅

To build on this secure foundation, here are handful of capabilities we are really excited about exploring with design partners and early testers:

• Audit logs:

  Do you know what identity pushed or pulled images from your registry? What if you had to go back in time and look up that information? We see this as an extremely valuable dataset for not only debugging purposes, but also for incident and response investigations, and it's a feature we’re excited about testing with early users.

• Provenance, signatures, SBOMs, CVE scans:

  Can you trace all the way back to the source code for containers in your registry? Are you being asked to produce SBOMs? How about CVE scans? We are looking at creating a feature that can automatically provide and make this data available.

• Policy enforcement:

  Want to enforce policies on images and artifacts that are pushed to your registry? We’re exploring ways to notify users when policy-violating images are pulled, and by whom or from where they were pulled.

• Secret scanning:

  Do you want a way to scan images pushed to your registry for secrets? This is a feature we want to build into the Chainguard Registry. If secrets are detected through scans, then no pulls for you.

And if that’s not enough, our team is exploring additional capabilities in the Chainguard Registry, including:

‍

• Enhancing security around authentication and authorization.

• Tiered caching with clusters for better latency and reliability outcomes, while still remaining auditable.

• Managed and automated mirroring capabilities to existing registries (ECR/GCR).

If you are interested in a container registry solution that puts security first in its design, and you want to be a part of this earlier tester experience, reach out and we’ll be in touch!