By submitting this form, you agree to our 

 is right around the corner, and there are quite a lot of changes to unpack! Removing enhancements with the status of “Deferred” or “Removed from Milestone” we have 59 Enhancements in all listed within the 

Kubernetes 1.34 brings a whole bunch of useful enhancements, including 45 changes tracked as ‘

’ in this Kubernetes release. From these, 

 are graduating to stable, including support for Direct Service Return (

) and overlay networking in Windows kube-proxy.

 features are also listed in the enhancements tracker, including a built-in capability for pods to authenticate to kube-apiserver using mTLS. This is especially cool as it's built from pieces that are easy for external projects to reuse to deliver additional functionality using X.509 certificates. Amongst other new benefits, DevOps teams will benefit from new container restart rules. These rules declare the container-specific logic that can be used to customise the restart behaviour of the container when it exited or crashed.

If you don’t have time to read the entire release report right now, Gerome Grignon provides an easy to consume, status overview of each feature release from 1.19 through to 1.34 - 

. The Cloudsmith team is really excited about this release and everything that comes with it! Let’s jump into all of the major features and changes in Kubernetes 1.34.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

“From a personal perspective, I find the introduction of CEL-based mutating admission policies in Kubernetes 1.34 incredibly exciting because it brings clarity and simplicity to an area that’s historically been complex and operationally heavy. For those dealing with the overhead of managing external mutating webhooks (whether for debugging latency issues, ensuring HA, and handling failure edge cases) this feels like a major leap forward. Being able to express common mutations declaratively using CEL, directly within the API server, eliminates an entire layer of moving parts while still retaining flexibility. It also aligns beautifully with the Kubernetes philosophy of declarative configuration, and I’m particularly excited about how this could streamline GitOps workflows and simplify secure, consistent policy enforcement across environments.”

Nigel Douglas - Head of Developer Relations

#4427 Relaxed DNS search string validation

“I'm really happy to see this KEP graduate to stable in Kubernetes 1.34 because it finally addresses a long-standing pain point when dealing with legacy or standards-bending DNS setups. In the past, trying to use valid-but-practically-common patterns like underscores or a single dot in dnsConfig.searches meant hitting a frustrating wall with 

 validation. This often forced awkward workarounds or even blocked legacy workloads from being migrated into Kubernetes entirely. With this KEP now stable, Kubernetes is acknowledging real-world usage patterns while still maintaining safe, opt-in behaviour.

From a practical standpoint, it's empowering for me to be able to configure a pod with dnsConfig.searches like abc_d.example.com without having to fight the platform. These are small changes, but they remove major friction, especially when you're dealing with SRV records or short-name resolution in systems not designed with strict DNS compliance in mind. The design is also thoughtful: it's gated, it respects compatibility boundaries, and it won't break clusters on upgrade or downgrade. To me, this shows Kubernetes is maturing in a way that balances standards compliance with usability, and that's worth celebrating.”

Esteban Garcia - Principal Software Engineer

#4639 VolumeSource: OCI Artifact and/or Image

“This is a game-changer. Allowing OCI images to be mounted as volumes is incredibly exciting for us. It means our customers can now leverage their existing OCI registries to seamlessly distribute ML models, configurations, and binaries directly to their pods. This move greatly simplifies artifact management, streamlines MLOps and CI/CD pipelines, and enhances security. All of it while using familiar, standard tooling. I can’t wait to document some new examples about this.”

Pablo Javier López Zaldívar - Technical Writer

Allow recreation of pods once fully terminated in job controller

 require dedicated pods per index, but issues arise when these pods are prematurely terminated due to factors like preemption or eviction. Currently, replacement pods are created immediately, which often results in failure to start - especially in clusters with limited resources or strict budgets. This premature creation can delay scheduling, as resources may not be available until the terminating pod has fully exited. Additionally, if cluster autoscaling is enabled, these early replacements may trigger unnecessary scale-ups.

To address this, the proposed change introduces more control and visibility into pod replacement behaviour for Kubernetes Jobs. The Job controller will now differentiate between active, failed, and terminating pods. A new 

 field will track the number of terminating pods, and an optional spec field will allow users to configure whether replacement pods should wait for termination to complete. This information can also support queueing controllers like Kueue in better quota calculation. The goal is to offer more flexible and efficient scheduling without affecting other workload APIs.

This enhancement introduces support for a 

. Currently, StatefulSets update their pods one at a time, which can be slow and inefficient for certain workloads. By allowing multiple pods to be updated simultaneously (up to the specified 

 value). This change enables faster and more flexible rolling updates for stateful applications.

The motivation stems from several real-world scenarios. For instance, StatefulSets preserve pod identities, making them ideal for applications that publish consistent metrics or rely on fixed pod names - something not possible with Deployments. Additionally, applications that perform lengthy startup tasks or can tolerate multiple replicas going down (e.g., follower nodes in a distributed system) would benefit from the faster updates enabled by 

 for tracking updates, offering simpler and more predictable revision management compared to Deployments. The proposal aims to make StatefulSets more feature-rich and deployment-friendly, while retaining their core identity-preserving capabilities.

Deployments in Kubernetes currently show inconsistent behaviour when dealing with terminating pods, depending on the rollout strategy or scaling activity. In some cases, it might be more efficient to wait for pods to fully terminate before creating new ones, while in others, launching new pods immediately is preferable. To address this inconsistency, a new field, 

, is proposed to give users control over when replacement pods should be created during deployment updates.

The goal is to let users define whether a Deployment should wait for pods to terminate before spinning up new ones or proceed without delay, all while respecting the chosen deployment strategy. Additionally, the status of Deployments and ReplicaSets would be enhanced to reflect the number of managed terminating pods. This distinction is important, as pods marked for deletion (with a 

 field. This can lead to temporary over-provisioning - especially during rollouts or unexpected deletions like evictions - causing resource strain, potential scheduling issues, and even unnecessary autoscaling, which may increase cloud costs in large-scale or tightly resourced environments.


This proposal outlines a plan to enhance Kubernetes scalability and performance by enabling consistent reads directly from the watch cache instead of querying etcd. The core idea is to ensure that cached data is up-to-date by leveraging etcd's progress events, which indicate the latest revision observed and guarantee that all future events will be newer. This mechanism allows Kubernetes to verify how fresh the watch cache is and safely serve consistent (

) reads from it, without needing to go back to etcd each time.

The motivation behind this change is significant: serving reads from the cache is far more efficient than querying etcd, filtering, deserialising, and garbage-collecting large numbers of objects. This is particularly impactful for node-originated requests, such as kubelets listing pods scheduled on their nodes. Instead of listing and filtering hundreds of thousands of pods from etcd, the cache can immediately return just the relevant data. Beyond performance, this also resolves the long-standing “

” issue, where reflectors could receive outdated data on startup due to defaulting to non-consistent reads.

The implementation plan includes using a consistent read to get the latest resource version, waiting for the watch cache to reach that revision (with repeated 

 calls every 100ms if necessary), and then serving the request once the cache is fresh enough. This approach introduces little to no extra scalability cost and enables Kubernetes to maintain correctness while improving efficiency - particularly in large-scale clusters.

 as a simpler, declarative alternative to 

 in Kubernetes. Many common mutation scenarios (such as adding labels or injecting containers) can now be expressed using concise 

 (Common Expression Language) expressions, significantly reducing operational complexity.

This method eliminates the need for running and managing external webhooks and provides better introspection and performance. Because these policies run in-process within the Kubernetes API server, they avoid the latency and reliability issues associated with webhooks and support automatic re-invocation when needed.

, depending on the desired semantics and compatibility needs. The structured merge strategy is preferred for its declarative nature and integration with 

A key feature is the use of CEL expressions to dynamically construct the partial object to be merged into the original request. For example, injecting a sidecar initContainer can be done using the following 

This enhancement provides a Kubernetes-native way to express and apply mutations with clarity, speed, and declarative consistency - without sacrificing flexibility. It also paves the way for policy frameworks to be built around in-tree mechanisms and reused across systems like GitOps or CI/CD, all without relying on external webhook infrastructure.

This proposal introduces a new approach to handling leader election transitions for key Kubernetes components (

) by allowing them to gracefully release their leadership lock and revert to a follower state without restarting the entire process. Currently, when a component loses leadership, it forcefully exits using 

, requiring the kubelet to restart it. This results in unnecessary overhead and prevents clean shutdowns. The proposed change, gated behind a new feature flag (

), aims to improve high-availability (HA) behaviour by enabling components to stop their internal controllers, release resources, and then attempt to reacquire the lease - all without exiting.

To implement this, the components' control loops will be updated to support proper context cancellation and cleanup when leadership is lost. Key technical changes include modifying the 

 callback, enhancing health check de-registration, and deferring or resetting resources upon leadership loss. While this offers clear benefits in reduced latency and better lifecycle handling, there are associated risks - such as memory leaks, failure to respect shutdown signals, and regressions from future code changes. These risks are mitigated through audits, new tests, best practice documentation, and conditional gating of shutdown logic.

This enhancement proposal introduces KYAML, a new output format for kubectl (invoked via 

 is a strict subset (or dialect) of YAML designed to be compatible with existing YAML tooling while avoiding many of YAML’s most common pitfalls. It emphasises syntactical rules that prevent ambiguous behaviour, such as always quoting strings to avoid unintentional type coercion (for example "

" being interpreted as a boolean), using explicit flow-style syntax (

 for maps), and eliminating reliance on whitespace sensitivity. These design choices make KYAML easier to read, write, patch, and template, particularly beneficial in tools like Helm.

The KEP also proposes making KYAML the standard format for all Kubernetes project-owned documentation and examples. The motivation stems from YAML’s complexity and its tendency to produce valid but incorrectly interpreted files due to issues like indentation or ambiguous values. While JSON is an alternative, it lacks comments and is less human-friendly. KYAML aims to blend the safety and clarity of JSON with YAML’s readability and flexibility. By updating examples and tooling to use KYAML, the project hopes to guide the ecosystem toward more reliable and error-resistant configuration practices.

 Implement a .kuberc file to separate user preferences from cluster configs

 phase, this feature will be enabled through the 

. Users can override this location using the 

). The kuberc file will serve as an optional configuration to separate user preferences from cluster credentials and server configurations. This proposal aims to introduce a new file dedicated to user preferences, which will offer better flexibility compared to 

, which currently under-utilises its preferences field due to the creation of new files for each cluster that mix credentials with preferences.

The kuberc file will provide a clear separation between server configurations and user preferences, allowing users to define command aliases, default flags, and other customisations. The file will be versioned to support easy future updates, and users will be able to maintain a single preferences file, regardless of the 

 environment variable. This proposal also suggests deprecating the kubeconfig preferences field to streamline configuration management. The kuberc file will be entirely optional, providing users with an opt-in way for custom kubectl behaviour without impacting any existing setups.

Nigel Douglas

Head of Developer Relations

Kubernetes 1.34 – What you need to know

Containers have been with us for a while and are ubiquitous in the Secure Software Development Life Cycle (SSDLC). According to some reports, 

 use containers for most or all of their production applications. It’s no surprise really, as containers provide consistency and standardization across the lifecycle while speeding up delivery pipelines. They revolutionized how we develop and deploy apps in the cloud and there is no sign of this changing anytime soon.

Like any part of the SSDLC, containers have security risks and can be breached. This can be due to misconfiguration of the containers, inherent vulnerabilities in the contained software, like missed OS patches, or vulnerabilities in the runtime code. These can manifest in various ways, but some common ones are vulnerabilities that provide root access to the OS, turn off security features, execute malicious code at run time, or run phantom processes silently in the background. And these breaches do happen. The most famous container breach is still the 2018 Tesla breach, where it was reported that hackers read AWS credentials from the breached containers and therefore gained further infrastructure access, allegedly launching cryptojacking operations using that infrastructure. So, with nearly 60% of organizations using containers in production, it's great to hear about Docker’s Hardened Images being announced last week.

 and records 11 billion pull actions on these images each month. Previously, they released Docker Official Images to provide confidence in the provenance of the images, SBOM support to give transparency on contents and Docker Scout for real-time insights. This focus on security has evolved again into Docker Hardened Images.

A hardened image is a container image prepared to reduce Common Vulnerabilities and Exposures (CVEs).

Ensuring they provide the core functions required

Reducing the target area for attacks by removing up to 95% of the contents

Providing a curation and governance process for images

The provenance and curation of these images should give organizations and developers confidence. Knowing that images will be checked and kept up to date by a reputable source like Docker can only be reassuring. However, the security of containers and images doesn’t stop here. At Cloudsmith, we are delighted to partner with Docker on this launch, as we know we can add more to securing container usage together.

The above image shows a typical example of how this works in practice. An organization’s CI/CD pipeline is configured to use Cloudsmith as a private registry for its artifacts, including container images. When a build is triggered during development, the CI/CD tooling requests the container image(s) it needs.

With an upstream proxy for container images configured, Cloudsmith will fetch the image(s) from Docker Hub. It is at this stage where a verifiable, trusted Docker Hardened Image can be fetched. There is no extra configuration required in Cloudsmith, so users can benefit from using these images right away. Pulling a Docker Hardened Image is the same as fetching any other image from Docker Hub. Maximum security and trust is built into the raw image. For customers that have specific compliance or security requirements, Cloudsmith will also enforce policies around licensing and vulnerabilities. 

See: link to enterprise policy management blog

. This ensures that organizations have the right blend of security at source and the flexibility to map to their own requirements.

How do organizations ensure developers use these images during code creation and the deployment lifecycle? Cloudsmith is already used by organizations worldwide for their Docker registries, and our advanced features provide tools built for global teams.

Our cloud native, global availability means an organization’s registries are available wherever its teams are. Policy creation and enforcement provide granular access to private and public images, ensuring a source of truth for the organization’s images and providing visibility to its security teams. We also support CI/CD workflows, meaning the organization can confidently see what is being promoted to production.

With seamless integration and zero tradeoffs between speed and compliance, combining the peace of mind provided by Docker Hardened Images with Cloudsmith’s Docker registry support and functions can produce even greater governance and confidence.

That's why we are delighted to collaborate with Docker for this launch, securing the software supply chain further than ever before.

Want to learn how to secure your software supply chain end-to-end?

Watch our webinar next week for an in-depth discussion on container security, hardened images, SBOMs, and how to build a zero-trust artifact lifecycle. 

 and get actionable insights from Docker and Cloudsmith experts.

Jack Gibson

Senior Software Engineer

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Before GitHub, everyone struggled to manage SVN (the “cool kid” at the time, pre-git), CVS, VSS, or, for the genuinely arcane, RCS. As a developer, there was trepidation with every check-in, hoping that nothing went wrong. Back then, source code management was held within a proverbial black box on some server you had to maintain, probably stuck under a colleague's desk in the corner.

Then, in 2008, GitHub emerged with a fully managed SaaS offering that gave developers and their teams visibility, control, and management.

Even before Cloudsmith was formed, Lee and I adopted GitHub in 2012. This was our first opportunity to move away from this insane black box, on-prem legacy so we could concentrate on the things that mattered. We never looked back.

Today, GitHub stores most of the world’s source code, both private and open source. Over the years, it has expanded its core functionality to include GitHub Actions and a limited Package Registry, among other enhancements.

Cloudsmith was built to solve the same challenges of visibility, control, and management but for the software supply chain and secure delivery, including binaries, artifacts, packages, and containers. In much the same way, it brings a fully managed SaaS offering to store most of the world’s packaged code, both private and open source.

Our primary goal was to help developers and operations remove the need for an artifact registry on a legacy black box on a server you had to maintain or even think about deeply. Instead, we provided the single source of the truth for all artifacts in a fully managed cloud-native platform leveraging all of the cloud’s positive attributes, including reduced infrastructure costs and the best scalability and performance, all at the click of a button, just like GitHub.

Today, Cloudsmith proudly sits beside GitHub in our customers' tech stacks, showcasing our commitment to “works well with others” and ensuring our customers have what they need to build secure and performant pipelines, distributing source and packaged code when and where it is required, whether internally consumed, or delivered across the world.

Our integration with GitHub gives development and DevOps teams an easy and secure way to manage source code and the resulting packages through:




Use GitHub as your IdP to sign into Cloudsmith.




Use our GitHub Action to publish packages to Cloudsmith across all popular formats.




Use GitHub as an OIDC provider for integrated authentication and more robust security.




We scan and tag your packages using scanning data sourced from GitHub's advisory databases for Hex, Java, .NET, Node.js, PHP, Python, Ruby, and Swift.




We work alongside GitHub and GitHub Advanced Security to protect software's ingress and egress risks.

With the advent of popularized Gen AI, there is now more than ever a wealth of data, with new ways to consume and query it. It’s an obvious next step to share that knowledge created by deep developer-interactive tooling like GitHub and lean into the knowledge Cloudsmith is capturing about the security and provenance of both open-source and closed-source software.

That’s why we launched Cloudsmith Navigator last year, to surface curated provenance information about open-source packages, powered in part by GitHub’s history of the source code. Navigator offers a glimpse into the nature of the holistic knowledge we have access to, and it’s this knowledge that forms the foundations of additional risk-based policies and controls.

A wise wizard once told me (okay, it was last weekend), “[it’s important] to bring more of the developer tools in the place where they already work.” In other words, you want to build a bridge towards existing tooling and make it easy for others to integrate rather than being isolationist and building all-in-one platforms that are anti-competitive. It makes sense to achieve genuinely “works well with others” and fits into our strategic thinking and positioning for Cloudsmith.

We believe it will take a village of partnerships, with at least two cathedrals (GitHub and Cloudsmith 🙂), to put the best guardrails in place to minimize the risks of open-source and closed-source software. That means continuing to partner with companies that share our cooperative mission to secure software delivery, like our friends at Docker, CircleCI, Stacklok, Chainguard, and GitHub.

How to Integrate Cloudsmith with GitHub Actions

Using GitHub Actions to Push Packages to Cloudsmith

Alan Carson

Co-founder and Chief Strategy Officer

Two Cathedrals: Cloudsmith + GitHub

User management is the backbone of secure and efficient software operations. As businesses grow and evolve, the tools they use must keep pace. Enter OKTA and Cloudsmith. OKTA, a titan in identity and access management, combined with Cloudsmith, the powerhouse of software artifact management, offers a solution that's both robust and user-friendly. This guide looks at how these platforms can be integrated to elevate your user management game.

User management is about controlling access to a system or application. It's a delicate balance: ensuring security while facilitating collaboration. Effective user management optimizes resource use, prevents unauthorized access, and tailors user experiences based on roles and needs.

The road to effective user management is often dotted with hurdles. These can range from setting up appropriate permissions, managing inactive users, to staying compliant with industry regulations.

Since its inception in 2009, OKTA has carved a niche for itself in the identity and access management sector. Its cloud-based platform, equipped with tools for user authentication, caters to businesses of all sizes, ensuring secure and seamless user experiences.

Okta offers a suite of features such as Provisioning, Single Sign-On (SSO), integration with Active Directory (AD) and LDAP, centralized user deprovisioning, multifactor authentication (MFA), and mobile identity management. These are complemented by adaptable policies tailored for organizational security. These capabilities are seamlessly integrated through the Okta Integration Network (OIN), a collection of pre-integrated applications. The OIN ensures that users can enjoy SSO login across all essential apps they interact with daily.

OKTA's strengths lie in its single sign-on capabilities, multi-factor authentication, and comprehensive lifecycle management. For those looking to streamline user management, OKTA's intuitive interface and extensive API integrations make it an indispensable tool.

Cloudsmith stands out as a leading software artifact management platform. It offers teams a centralized hub to store, manage, and distribute software artifacts, ensuring that software components are consistently available and secure.

Users can upload data, software, and dependencies into Cloudsmith or pull it from third-party sources. We then control distribution to their developers, servers, or external customers. Our primary mission is to contain 100% of the software and related data for users within Cloudsmith, keeping everyone safe.

But of course, we understand that different users have different needs. While some may be uploading artifacts, others might be in roles that require only viewing or downloading capabilities. Effective user management in Cloudsmith ensures that each user has the right permissions, enhancing security and operational efficiency.

Pairing OKTA with Cloudsmith is like merging the best of both worlds. Cloudsmith's prowess in artifact management is complemented by OKTA's user management capabilities. This integration not only simplifies access but also amplifies security measures, ensuring that the right people access the right artifacts at the right time.

Setting up the OKTA integration is quite straightforward, and to help you through the process we have put together a 

 in our Help Center. The integration includes SCIM provisioning, making it easier to manage users in your organization with minimal impact to your workflows.

Cloudsmith’s OKTA integration not only allows for user management, but also group management. This allows your organization to define clear user roles and groups based on job responsibilities and access levels.

Automated Provisioning and Deprovisioning

One of the standout features of Cloudsmith's OKTA integration is the ability to automate user provisioning and deprovisioning. This automation is crucial for organizations that prioritize security and efficiency.

When a new team member joins, the onboarding process often involves granting access to multiple tools and platforms. With automated provisioning, as soon as a user is added to OKTA, they're automatically granted access to Cloudsmith, eliminating manual steps and potential oversights. Conversely, when an employee leaves or changes roles, their access can be automatically adjusted or revoked, ensuring that only current team members have access to your critical systems.

Cloudsmith's OKTA integration can be seamlessly connected with HR systems. This means that any changes in the HR system, such as a new hire or a departure, can trigger the appropriate provisioning or deprovisioning actions in Cloudsmith. This integration further streamlines the user lifecycle management, reducing administrative overhead and potential errors.

It is not uncommon for user data to be scattered across multiple systems, and we all know how difficult that can be to manage! This fragmentation can lead to inconsistencies, security vulnerabilities, and administrative headaches. Cloudsmith's OKTA integration addresses this challenge head-on by ensuring that OKTA serves as the single, central source of truth for user information.

When OKTA is the authoritative source, any changes made there—like updating an email address or changing a department—will automatically sync to Cloudsmith. This ensures that user data remains consistent across platforms. By centralizing user information, organizations can reduce the risk of data discrepancies, improve auditability, and simplify user management.

Learn more about getting started with creating and managing teams in in Cloudsmith in the short video below:

Teams and Access Controls

As organizations increasingly rely on platforms like Cloudsmith for their operations, ensuring the protection of user data and maintaining a secure user management system becomes paramount. Let's delve into the security considerations you should be aware of when managing users with Cloudsmith and OKTA.

User data is a valuable asset, and its protection is non-negotiable. Cloudsmith is committed to safeguarding this data, implementing stringent security measures that align with industry best practices. When integrated with OKTA, the data protection capabilities are further enhanced. OKTA employs robust encryption methods, both in transit and at rest, ensuring that user data remains confidential and tamper-proof. Regular security audits, penetration testing, and compliance certifications further attest to the platform's commitment to data protection.

Role of OKTA in Enhancing Cloudsmith's Security

OKTA doesn't just streamline user management—it amplifies security. By integrating with Cloudsmith, OKTA brings its advanced security features, such as multifactor authentication (MFA), to the table. MFA requires users to provide multiple forms of identification before gaining access, significantly reducing the risk of unauthorized access. Additionally, OKTA's adaptive authentication measures assess various risk factors, like location and device, adjusting authentication requirements based on the perceived risk level. This dynamic approach ensures that security doesn't come at the expense of user experience.

Tips for Maintaining a Secure User Management System

: Periodically audit user roles and permissions. Ensure that employees only have access to the resources necessary for their roles.

: Ensure that all systems are regularly updated. Security patches and updates address vulnerabilities and enhance overall system security.

: A secure system is only as strong as its weakest link. Regularly train your team on security best practices, emphasizing the importance of strong, unique passwords and recognizing phishing attempts.

 Set up monitoring to detect any unusual activities. Immediate alerts for suspicious actions can help in quickly identifying and mitigating potential security threats.

: While not strictly a security measure, regular backups ensure that you can quickly recover user data in the event of any unforeseen circumstances, be it a technical glitch or a cyberattack.

The integration of OKTA with Cloudsmith is a testament to the evolution of user management in the digital age. By combining the strengths of two industry leaders, organizations can ensure a seamless, secure, and efficient user management experience. As the digital landscape continues to evolve, so do the challenges associated with user management. However, with tools like OKTA and Cloudsmith, businesses are well-equipped to navigate these challenges, ensuring that their operations remain secure, streamlined, and scalable. Whether you're just starting out or looking to enhance your existing setup, the OKTA-Cloudsmith integration offers a robust solution that caters to the diverse needs of modern organizations.

Lee Skillen

Chief Technology Officer

Managing Users and User Groups: A Guide to OKTA and Cloudsmith Integration

 Docker is retiring Docker Content Trust (DCT), and it's time to migrate to open standards like Sigstore. If you're a Cloudsmith user, you're already ahead, since Cosign-based image signing is built-in. Here's how to make the move.

 launched with the goal of giving developers a way to verify the integrity and publisher of container images. It was built on The Update Framework (

Fast forward to 2025: Notary is no longer actively maintained, the industry has evolved, and 

 of Docker Hub image pulls use DCT. Microsoft is dropping support in Azure Container Registry, and now Docker is formally beginning to retire DCT. This starts with Docker Official Images (

If you're using DCT in your pipelines, things may already be breaking.

But there’s good news: the ecosystem is moving forward through 

, an open standard built for the modern software supply chain.

Provenance is becoming a critical part of how we secure the modern software supply chain. At its core, it’s about traceability: being able to answer where a software artifact came from, how it was built, and who was responsible at each stage of the process. Threat actors continue to increasingly target dependencies, build systems, and distribution infrastructure, meaning verifiable metadata about your software’s origin is really important. Being able to establish the provenance of your container images helps teams make informed, trustworthy decisions about what they built, run, and deploy. It’s a key building block for adopting frameworks like 

, and is top of mind for teams in highly regulated environments.

But knowing what happened during a build isn’t enough, you also need a way to attest to that information in a way that others can verify, without adding unwanted friction. So when you think, “why do I need Sigstore?” - that’s the reason. Sigstore is an open-source project that enables cryptographic signing of software artifacts like container images using standard tooling like Cosign, Fulcio, and Rekor.

Unlike DCT, which relied on TUF until the upstream Notary codebase was no longer actively maintained, Sigstore has an active community of contributors and is integrated into a long list of 

Sigstore makes it easy to integrate signing and verification into your CI/CD pipeline without the need for custom certificate infrastructure requirements. You can use keyless signing (via OIDC), or generate and manage your own keys.

While both Sigstore and TUF aim to improve the same software supply chain security issues, they address different layers of the trust and verification problem. For instance, TUF focuses on securing software update systems. It defines certain roles (such as root, targets, and snapshots) as well as providing a metadata-driven approach to protect against rollback attacks or mix-and-match attacks. TUF’s strength and differentiation is in its resilience, so even when some keys are compromised, it can still recover securely.

Whereas, Sigstore is designed specifically for artifact signing and transparency, especially within CI/CD-related contexts. Likewise, Sigstore offers a developer-friendly approach to cryptographic signing, as stated already, it leverages OIDC-identity (keyless) signing, open and auditable transparency logs through Rekor, and dedicated integration with Fulcio for certificate issuance.

Fundamentally, these two approaches have key distinctions in that Sigstore ties identities to signatures (like Github Identity), whereas TUF focuses only on robust update metadata and key delegation. If you’d like to learn more about how these two solutions differ, Bob Callaway and Dan Lorenc delivered a

 on the topic of why Sigstore was created.

Again, Cloudsmith already has native support for Sigstore's Cosign. When you enable “cosign signing" for your repository, every Docker image uploaded to a Cloudsmith repository is 

An ECDSA private key is generated when you create a repository.

Images are signed automatically on upload using this key.

You can download the matching public key to verify signatures.

Or you can use your own Cosign keypair and upload external signatures via the 

This means Cloudsmith customers already have a modern, secure signing solution in place without the need to scramble around for a replacement DCT.

Migrating from Docker Content Trust to Sigstore (Cosign)

 and TUF, which allowed for signature-based verification of container images. But with DCT now deprecated and official support ending, it's time to transition to modern, open tooling.

Here is how to migrate to Cosign with Cloudsmith:

 set in your environment, unset it. Continuing to use DCT after August 8, 2025, will cause failures when pulling Docker Official Images. Unsetting the below environment variable will avoid any unwanted pull failures:

To verify a signed image from Cloudsmith:

 feature flag tells Cosign not to query the Rekor transparency log, which is appropriate since Cloudsmith-hosted signatures are private by default.

In scenarios where you’re using a default Cloudsmith-managed keypair, you’ll need to download the associated ECDSA public key (making sure to replace 

 with your actual Cloudsmith workspace and repository names):

3. Sign images yourself (totally optional)

Prefer signing artifacts manually? You can generate and upload Cosign signatures directly:

Then upload both the image and signature to Cloudsmith. We’ll store and associate them automatically.

Cloudsmith does not log signatures to Rekor when signing on upload, because most customers use private repositories. As a result:

Cosign will warn if you attempt to verify without setting 

To avoid confusion, always include the flag when verifying Cloudsmith-hosted signatures:

f you want to use Rekor for transparency, you can opt into it by signing manually with Cosign and uploading both the signature and the image to Cloudsmith.

. By migrating from Docker Content Trust to Sigstore (via Cosign), you're adopting an open, scalable approach to supply chain security, while simultaneously staying compliant and adhering to industry best practices. And with Cloudsmith, this migration is already built in.

Migrating from Docker Content Trust to Sigstore

Large Language Models (LLMs) are now at the cutting edge of mainstream AI systems. Their impact has been seismic, sparking a new gold rush as application developers transform the user experience away from clicks and commands into natural language and advanced automation

However, application developers have a barrier to overcome. AI models need data to reason and respond to a particular application domain. Say, for example, the user of an artifact management platform needs to pose a simple question, ‘What packages are trending upward in usage?’ To answer this question, the AI needs to be trained on package data, including usage data.

In general, an AI model's capabilities depend on the information, or context, on which it is trained. And here is the problem - AI models tend to be isolated from data. Getting data into the AI model is not trivial. The data is often behind information silos and legacy systems. Integrating models usually involves a custom implementation with bespoke connectors.

It’s as if each time you plugged a device into a computer’s USB port, you had to configure the connection on a per-device basis. And so it is with AI models. The implementation has to be done on a per-data source, per-AI model basis, each time needing its own connector, protocol, and security checks. This multiplies the work involved in integration and tethers the LLM to a particular source, making it difficult to scale.

This multiplicity of connectors between each model and each source has been termed the MxN problem. Every model (M) needs a custom integration for every source or service (N), creating a multitude of one-off adapters that create a build and maintenance headache. As more models and tools enter the ecosystem, the integration load grows exponentially.

Luckily, Anthropic devised a solution to solve the mess of custom integrations that results from the MxN approach. The Model Context Protocol (MCP) is an open standard that provides a universal way of connecting AI models to external data sources and systems.

MCP provides a common interface, regardless of data source, eliminating the need for custom integrations for models and sources. The use of MCP as a middle layer reduces the MxN problem to a much more scalable M+N, as each model and source only has to integrate with MCP.


The USB-C port analogy is often used for MCP, as it, too, uses a single connectivity standard to provide a universal way to connect different devices. In fact, any common protocol has the same kind of utility. HTTP created a universal language for web browsers and servers to interact. MCP enables interoperability across platforms like OpenAI, Anthropic, Google DeepMind, and Microsoft, giving AI assistants access to tools and repositories in a secure and standardized way.

MCP is built using a client-server architecture, and works as follows:

The AI model (host) uses connectors (clients) to send requests for information or actions using MCP to an MCP server.

The server receives the requests, acting as an abstraction layer in front of the data source, exposing a controlled set of functions.

The server then translates the model’s requests into safe, scoped operations. This means data is accessed securely and consistently, and the model doesn’t need to know server implementation details for each data source.

The server capabilities are exposed via JSON-ROC methods, which are mapped to one or more internal database queries or functions. These could include file lookups, data queries, transformation functions, or any other tool-like operation.

The AI model can introspect the available methods and call them with specific parameters. The server authenticates the request and calls the appropriate backend query using its own connection to the database. A structured response is then returned to the model. This completely decouples the database logic from the AI model.

MCP provides powerful capabilities through code execution and data access. To address this, MPC includes a series of recommendations for best practices for securing data within your infrastructure.

These best practices are shaped around four key principles:

- Users must explicitly consent to and understand what data is accessed and what actions are performed. Implementations should offer clear UI elements to authorize and review activities.

- Resource data must not be transmitted or exposed without user approval. All access must be explicitly granted and protected through proper controls.

Cloudsmith Blog

Kubernetes 1.34 – What you need to know

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Two Cathedrals: Cloudsmith + GitHub

Managing Users and User Groups: A Guide to OKTA and Cloudsmith Integration

Migrating from Docker Content Trust to Sigstore

Adding AI to applications using the Model Context Protocol

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

Kubernetes 1.33 – What you need to know

Integrating Dependabot with Cloudsmith Using OIDC

GitOps Pipelines with Codefresh and Cloudsmith

Announcing the Release of Cloudsmith CLI GitHub Action 🚀