By submitting this form, you agree to our 

 is fast approaching, and it’s a loaded update! Removing enhancements with the status of “

” we have 59 Enhancements in all listed within the 

Kubernetes 1.35 brings a whole bunch of useful enhancements, including 30 changes tracked as ‘

’ in this Kubernetes release. From these, just 

 are graduating to stable, such as the addition of Kubelet option to specify the maximum age an image that will be kept around before it’s garbage collected. This is beneficial to cluster admins because unused images can now be garbage collected in a timely manner, no longer occupying disk space forever.

 features are also listed in the enhancements tracker, one of which introduces some new authorisation rules to restrict impersonation on specified resources with specified actions. We also see support for in-place resizing of pod-level resources, support for restarting all containers within the pod when a container exits as a 

This is the most detailed Cloudsmith release notes to date, and our team is really excited about this release and everything that comes with it! Let’s jump into all of the major features, changes, and deprecations in Kubernetes 1.35.

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

I’m excited to see structured auth config graduate to stable in Kubernetes 1.35 because it marks a major step forward in making cluster authentication both more flexible and maintainable. The current flag-based OIDC setup has long been a pain point, as it’s hard to extend, oftentimes difficult to manage, and is limited in how it maps identity claims. Moving to a versioned, structured configuration not only modernises this critical component but also unlocks long-requested capabilities like supporting multiple client IDs, richer claim mappings, and dynamic reloading of authentication settings without restarting the API server. This enhancement brings much-needed clarity and power to authentication workflows, simplifies life for operators, and sets a strong foundation for future innovations in identity and access control in Kubernetes.

Nigel Douglas - Head of Developer Relations


The feature I’m happy to see graduating to beta status in Kubernetes 1.35 is the binding conditions within Dynamic Resource Allocation. This looks to be a significant step towards making Kubernetes the definitive platform for demanding AI/ML workloads. This improvement provides the critical intelligence for schedulers to handle complex, disaggregated hardware like fabric-attached GPUs robustly, preventing failed deployments and enabling more efficient, dynamic resource allocation. The beta graduation signals that this powerful feature is almost stable and ready for broader adoption within the ecosystem, hopefully paving the way for more resilient, dedicated AI infra in Kubernetes.

#3673 Kubelet limit of Parallel Image Pulls

We are all delighted to see this new Stable update address the existing, ineffective method Kubernetes currently uses to limit container image pulls on a node. The existing QPS (Queries Per Second) and Burst limits are really confusing as they only control the rate of requests to the container runtime, not the number of concurrent pulls. This can sadly lead to an unlimited number of simultaneous downloads, potentially overwhelming a node's disk I/O and network bandwidth. This new change adds a more intuitive kubelet config field called 

. This setting establishes a clear, node-level limit on how many images can be pulled at the same time. Any pull request that exceeds this limit will be blocked until an ongoing pull completes - improving how cluster admins manage their resource consumption.

maxUnavailable for StatefulSets rolling updates

 strategies. Previously, when updating a StatefulSet, pods were terminated and recreated strictly one at a time, which could be very slow. This enhancement allows users to specify the maximum number of pods that can be unavailable during an update, either as an absolute number or a percentage. This means multiple pods can be updated simultaneously, dramatically speeding up the rollout process.


The primary motivation is to make StatefulSet updates faster and more flexible, bringing them closer to the functionality of Deployments. This is particularly useful for stateful applications that can tolerate multiple replicas being down at once (like a cluster with many followers) or for applications with long startup times (like cache loading). By allowing parallel updates, this feature helps users who prefer the stable network identities of StatefulSets but need the faster rollout capabilities typically associated with Deployments. The default value for 

, ensuring backward compatibility and maintaining the safe, one-by-one update behaviour for applications that require it.


 field to the Kubernetes Job specification. Its primary purpose is to delegate the management and status synchronisation of a Job to an external controller, effectively telling the default Kubernetes Job controller to ignore it. This is a lightweight, per-Job mechanism designed to prevent conflicts when another system needs to take control. The main motivation for this is to support 

, a multi-cluster job dispatcher that runs a "mirror" copy of a Job on a separate worker cluster while managing the original Job on a central management cluster. The 

 field allows the MultiKueue controller to sync the status from the worker cluster back to the management cluster without the default controller interfering.

, meaning it can only be set when the Job is created and cannot be changed later. This choice was made to avoid complex issues and potential errors, such as "leaking" pods, which could occur if control of a running Job were switched between different controllers. This approach provides clear ownership throughout the Job's lifecycle and follows a pattern already used by other Kubernetes resources, making it a stable and predictable solution for developers of custom batch processing systems.

Mutable Container Resources when Job is suspended


This Kubernetes enhancement proposes allowing users to modify the container resource requirements (like CPU and memory) on a job's template while that job is suspended. Currently, this is not possible. The primary motivation is to give users, particularly those using queuing systems like 

, the flexibility to adjust a job's resource needs before it resumes, which can improve scheduling efficiency. While a proof-of-concept exists for standard resources, the implementation faces a significant hurdle with the newer Dynamic Resource Allocation (

) framework, as its resource templates are immutable, and a clear path forward for DRA support is still under discussion.


Initially, the team considered releasing this feature directly as a 'beta' version, enabled by default, viewing the risk as low. However, concerns arose about completing the necessary comprehensive testing within a short development cycle. Specifically, addressing potential race conditions, such as one user updating resources while another unsuspends the job was deemed critical but complex to test reliably. Given these challenges and the potential for unforeseen consequences when loosening API validation rules, the consensus shifted. It looks like the feature will now be introduced in an 'alpha' stage to allow for more iteration and the development of robust test coverage, ensuring the feature is stable and safe before being promoted.

 aims to address the version skew issues within Kubernetes clusters during upgrades or downgrades by ensuring that clients always interact with a complete view of the cluster's capabilities. To achieve this, the proposal introduces a proxying mechanism where an API server, upon receiving a request for a built-in resource it cannot serve locally, identifies and forwards the request to a peer server that can. This prevents misleading "404 Not Found" errors. Simultaneously, the feature implements 

, which merges resource information from all peer API servers into a unified discovery document. This ensures that clients using the aggregated discovery endpoint receive a comprehensive list of all available resources across the cluster, regardless of which individual server they contact.

This mechanism is critical for maintaining system stability and data integrity during version transitions. Without it, controllers like the 

 might act on incomplete information, potentially leading to the incorrect deletion of objects or operational deadlocks. By ensuring that requests yield either the correct resource or a safe "503 Service Unavailable" (rather than a "404"), the system protects against destructive actions while allowing valid operations to proceed. It is important to note that this peer-aggregation logic applies only to the aggregated discovery endpoint (

) and excludes the legacy core endpoint (

 group's top-level types are considered frozen and will not require dynamic merging.

: AuthorizePodWebsocketUpgradeCreatePermission 

In Kubernetes v1.35, a new Beta security feature for synthetic RBAC CREATE Authorisation checks has been introduced as part of this Stable graduation. This feature enhances security by forcing an additional authorisation check when a user attempts to establish a persistent, two-way connection to a pod using commands like 

. Previously, these actions were authorised with a 

 permission; now, this update adds a check for a 

 permission on the corresponding subresource. This ensures that only users with appropriate creation rights can initiate these powerful, interactive sessions with pods.

This security enhancement is part of a much larger and more significant update: the migration from the outdated 

 for streaming communication. The SPDY protocol has been deprecated since 2015 and is no longer supported by many modern proxies and load balancers, causing connectivity issues. By transitioning to WebSockets, a current industry standard, Kubernetes ensures better compatibility and reliability for essential developer commands. In essence, this update modernises a critical communication pathway in Kubernetes while simultaneously tightening the security around it.


Kubernetes occasionally needs to rewrite stored resource data, a process essential for maintenance activities like upgrading a resource's schema version (example: from 

) or re-encrypting data at rest after an encryption key change. The traditional method for this, using manual 

 commands, is inefficient and impractical, especially for large resources like Secrets, and does not scale as the number of resources grows. This manual process is cumbersome and requires significant automation to be performed reliably across a cluster.


To address these challenges, this Kubernetes Enhancement Proposal (

 for short) suggests integrating the logic from the existing Storage Version Migrator (

) tool directly into the Kubernetes Controller Manager (

). This would create a native, in-tree controller and API dedicated to storage migration. The primary goal is to provide administrators with a simple, reliable way to trigger these migrations without manual commands. This change would enable infrastructure providers to automate migrations in response to environmental events, such as a key rotation in a Key Management Service (

), and would streamline the process for users who currently rely on the external SVM tool. While the migration process will be simplified, the responsibility to initiate it will remain with the user.

 Remove gogo protobuf dependency for Kubernetes API types


In early October, the Kubernetes development team initiated a significant change by starting the process of removing a dependency called 

. This component is a toolchain that Kubernetes has been using to automatically generate the Go code necessary for handling its REST API data structures. The core of this feature is to replace an unmaintained and outdated part of the Kubernetes system to enhance security, stability, and future maintainability.

The primary motivation for this change is that gogo protobuf has not been maintained since 2021, which introduces several risks. Relying on an unmaintained dependency means that any newly discovered security vulnerabilities or bugs cannot be easily fixed. Furthermore, every developer or business that uses Kubernetes' core libraries is forced to inherit this unmaintained dependency, creating a wider security concern. This change also aims to prevent accidental misuse of the API types with standard 

 libraries, which has caused system crashes in other projects. By removing 

, the generated code will be streamlined to include only what is essential for Kubernetes client and server operations, making the system more robust and secure.


This now merged pull request formalises the behaviour of the 

 field. Currently, clients are meant to treat 

 as an opaque string, only allowing for equality checks. However, the internal Kubernetes API server implements it as a monotonically increasing integer. This enhancement officially defines that 

should be a comparable, monotonically increasing integer

, allowing clients to reliably determine the order of resource updates, which is a growing need. The proposal includes adding a utility function for clients to safely compare two resource versions and adding conformance tests to ensure API servers adhere to this standard.


A key debate in the comments centred on how to handle non-compliant extension API servers. One alternative suggested was an opt-in mechanism where APIs could advertise their 

 comparability through the discovery API. However, the consensus was that this added unnecessary complexity. Instead, the accepted approach pushes API server authors to either use a comparable integer (the preferred state) or a clearly non-integer string. The new client-side utility function would handle the latter case by returning an error, preventing misinterpretation. The enhancement proposal was ultimately approved and merged, strengthening the API contract for all clients.

 Separate kubectl user preferences from cluster configs

, designed to separate user-specific preferences from cluster credentials and server configurations, which are typically managed in 

 files. The primary motivation is to allow users to define consistent client-side behaviours, such as command aliases, default flags, and security policies, that would apply across all clusters without altering the 

 files used in different environments, like CI/CD pipelines. This separation ensures that personal settings, like enabling interactive delete confirmations or coloured output, don't break automated scripts, and preferences remain consistent even when switching between multiple kubeconfig files.

, is a versioned YAML file that enables users to create custom command aliases and set default options for standard 

 commands. For example, a user could create a short alias for a complex 

 command or automatically enable the server-side applies and the interactive deletes. The proposal also includes a new 

 command to help users safely view and manage these settings without manually editing the file. This feature is opt-in and aims to enhance the user experience by making 


Having gone from New State status to Alpha in Kubernetes 1.34, 

 is now graduating to Beta status. If you missed this feature announcement in Kubernetes 1.34, KYAML is a new, opinionated output format for 

 designed to be a stricter, less error-prone subset of standard YAML. It was created to address common frustrations with conventional YAML, such as its sensitivity to whitespace which complicates templating in tools like Helm, and its ambiguous data typing where unquoted strings like "NO" or "On" can be incorrectly interpreted as booleans (a problem known as the "

"). While JSON is an alternative, it lacks crucial features like comments. KYAML aims to provide the best of both worlds by defining a "flow style" dialect that is 100% compatible with existing YAML parsers but enforces syntactical choices that increase clarity and reduce common user errors, making configuration files easier to write, read, and manage programmatically.


The core principle of KYAML is to use syntax that removes ambiguity and reliance on indentation. It achieves this by always using curly brackets (

) for maps and structs, square brackets (

) for lists, and double quotes for all string values. This approach makes the format insensitive to whitespace, similar to JSON. However, unlike JSON, KYAML is more human-friendly, allowing for comments, trailing commas in lists and maps, and unquoted keys where safe. The proposal includes introducing a new 

 command and updating all official Kubernetes documentation and examples to promote this safer, more consistent format throughout the ecosystem.

For example, here is a KYAML output for a Kubernetes 

 Include kubectl command metadata in HTTP request headers

This new enhancement in K8s v.1.35 suggests adding contextual HTTP headers to requests sent from 

. The goal is to give cluster administrators better visibility into how users are interacting with the cluster for debugging and telemetry purposes. Currently, while the API server sees requests from 

, it doesn't know the specific command that initiated them (like 

). This proposal introduces new headers, primarily 

 header will contain the full command path (for example, 

 will provide a unique ID to group all API requests that originate from a single kubectl command invocation.


This added information is intended purely for out-of-band analysis, such as identifying the use of deprecated commands, understanding usage patterns to inform tooling decisions, or simplifying debugging. It is explicitly stated that the API server should not make any decisions based on these headers. Flag values and command arguments will not be included to protect sensitive information.

 command would generate API requests that include the proposed new headers, which could then be seen in the API server's audit logs.

Nigel Douglas

Head of Developer Relations

Kubernetes 1.35 – What you need to know

 is right around the corner, and there are 11 clear new Python Enhancement Proposals (PEPs) added to the Python project! There are several over significant changes listed within the 

Python 3.14 brings a whole bunch of useful build improvements, including discontinuation of PGP signatures in 

. Python versions 3.14 and onwards will no longer provide PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. Similarly, free-threaded mode (

), which was introduced in the previous version, 3.13, has undergone major enhancements. The implementations outlined in this enhancement are now complete, incorporating updates to the C API, and the interpreter’s earlier temporary fixes have been replaced with long-term solutions.

The Cloudsmith team is really excited about this release and everything that comes with it! Note that some of the statuses may change between the time of this blog being posted and the final release date. Knowing that, let’s jump into all of the new features and improvements in Python 3.14.

PEP 761: Discontinuation of PGP signatures

“From my perspective at Cloudsmith, the move away from PGP signatures in Python is a welcome change. PGP has long struggled with usability and the burden of managing long-lived private keys, and while it was the default for artifact signing, it never felt ideal. Sigstore offers a much more practical approach, using short-lived keys tied to human-readable identities, and it’s already gaining traction across ecosystems like PyPI, NPM, Homebrew, and GitHub. We’re also seeing projects we work with, like 

, embracing Sigstore, which reinforces that this shift is a real step forward for security and usability.”

PEP 734: Multiple interpreters in the stdlib

“This was an inevitable development, in my opinion. While the CPython runtime has supported running multiple interpreters, which are independent copies of Python within the same process, for well over 20 years at this point, the feature was still limited to the C-API and thus saw little adoption due to low awareness and the absence of a standard library module. With Python 3.14 introducing the new 

 module, this long-standing capability is finally becoming more accessible, marking a significant step toward mainstream usage. While current limitations remain, their impact will diminish as CPython evolves and the community contributes solutions via 

PEP 784: Adding Zstandard to the standard library

“Python 3.14’s addition of Zstandard (via 

) is an exciting upgrade because it brings one of the fastest, most efficient modern compression algorithms directly into the standard library, alongside a new unified 

, consistently outperforms older formats like 

 by offering both higher compression ratios and dramatically faster decompression speeds, which has made it the de facto standard across filesystems, packaging tools, and industry at large.

By including it natively, Python eliminates the confusion of multiple third-party bindings, enables direct support in core modules like 

, and opens the door for faster, smaller Python wheels and other packaging improvements. The reserved 

 namespace not only avoids naming conflicts with PyPI packages but also creates a clean, future-proof home for compression libraries, much like 

 does for hashing. This change reflects Python’s “batteries included” philosophy while giving developers a state-of-the-art compression tool that is both practical today and well-positioned for long-term usage.”

Free-threaded Python is now officially supported

 this enhancement proposal, which actually sets requirements for advancing 

, which was the larger, ongoing effort to make Python’s 

) optional. PEP 703 outlines a three-phase plan:

First phase introduces an experimental GIL-free build in Python 3.13

Phase two makes this build officially supported - though still optional

While Phase 3 makes it the default. 
This new feature defines the expectations for the second phase, ensuring the free-threaded build is stable, usable, and performant enough for broader adoption.

The motivation behind this shift is to balance the benefits of free-threaded Python, which offers greater concurrency, reduced latency, and expanded threading capabilities against costs such as performance penalties, memory overhead, and ecosystem complexity. Current benchmarks show around a 10% slowdown and 15-20% more memory use compared to the traditional GIL build, both considered acceptable trade-offs for Phase 2.

The APIs introduced so far have proven stable, and further refinements are expected without breaking changes. With growing third-party support and clear criteria for performance, memory use, documentation, and API stability, Python 3.14 is targeted as the point where free-threaded Python becomes an officially supported build.

Standard Library Support for Isolated Python Interpreters

Python 3.14 sees the addition of a new standard library module, 

, to expose CPython’s long-standing support for multiple interpreters in a single process. Each interpreter is strictly isolated, with its own modules, classes, and variables, while sharing only certain immutable or low-level process state. Unlike threads, which share most of the same runtime state, interpreters provide stronger isolation, making them better suited for parallelism, especially now that 

The new module will provide a high-level interface for creating, inspecting, and executing code in interpreters, as well as managing communication through a built-in, cross-interpreter-safe 

. This brings powerful functionality, previously limited to the C API, into Python code. An additional 

concurrent.futures.InterpreterPoolExecutor

 will be provided to simplify concurrent workloads.

The interpreters module defines an Interpreter object with methods like 

 to initialise globals. Interpreters can safely exchange data using 

, which supports pickle-based transfers and special handling for buffer objects like 

. This queue acts as a synchronisation and communication mechanism, enabling patterns like worker coordination across interpreters. For example, the below snippet taken from the PEP documentation shows multiple interpreters sharing a 

 of large data, synchronised with a queue token:

Making Parentheses Optional in Except and Except Blocks

 blocks in Python, users can now catch multiple exception types, so long as the “

” operator clause is not used. Currently, parentheses are mandatory around multiple exception types, a requirement carried over from Python2.

Removing this requirement simplifies the syntax, improves readability, and makes it more consistent with other comma-separated constructs in Python, such as function arguments and tuple literals. Parentheses will still be required when using as to capture the exception instance to avoid ambiguity. The change is purely syntactic, fully backwards compatible, and does not alter exception handling semantics.

Deferred Evaluation Of Annotations Using Descriptors

Python annotations let developers attach type information and metadata to functions, classes, and modules. Traditionally, annotations were evaluated eagerly when the object was defined, which led to common problems with forward references and circular dependencies. 

 attempted to fix this by “stringizing” annotations (storing them as strings), solving the forward-reference issue but breaking runtime use cases where actual objects were expected instead of strings.

A new proposal introduces a third, more flexible approach: lazily evaluating annotations through a dedicated 

 method. At compile time, Python generates a helper function that constructs the annotation dictionary, then attaches it to the object as 

. Accessing these annotations triggers this function, evaluates the annotations only when needed, and caches the results. This design eliminates circular-reference issues, preserves runtime usability, and allows for new introspection capabilities. Furthermore, 

 gain a new format parameter, letting users choose between evaluated values, forward-reference proxies, or source-code strings for annotations.

Here’s a simplified illustration of how this lazy evaluation model works:

With this change, annotations retain their runtime meaning while still avoiding forward-reference pitfalls, which supersedes the enhancement #563 string-based approach mentioned earlier, as well as offering a unified solution for both static and runtime use cases.

Safe external debugger interface for CPython

This introduction of a zero-overhead debugging interface for CPython should allow debuggers and profilers to safely attach to running Python processes. By providing well-defined safe execution points within the interpreter’s evaluation loop, external tools can request code execution without modifying normal execution or introducing runtime overhead.

This mechanism enables scenarios like attaching pdb to live processes by PID, similar to 

, allowing developers to inspect, evaluate, and step through running Python code interactively without stopping or restarting applications. Current approaches to live debugging in Python are risky because they rely on unsafe code injection, which can execute at arbitrary points in the interpreter, leading to crashes, memory corruption, or deadlocks. By integrating a small support structure into each thread state and extending the debug offsets table, this proposal ensures that debugging code is executed only when the interpreter is in a consistent and safe state.

The interface works by having debuggers write control information, such as the path to a Python script, into dedicated memory locations in the target process. The interpreter checks for pending debugger requests at existing safe points (via the 

), executing the provided code without interrupting critical operations like memory allocation or garbage collection.

 API simplifies remote execution for external tools, while environment variables and build flags allow redistributors and administrators to disable the feature if desired. Multi-threaded considerations are handled naturally: injected code runs under the normal GIL, ensuring thread safety, and can target individual threads or all threads as needed. This approach aligns Python with other major languages in live debugging capability while maintaining safety and zero runtime overhead during normal execution.

Deprecating PGP signatures for CPython artifacts

Again, this PEP isn’t merely a deprecation announcement. Instead, we see the introduction of an entirely new security model through Sigstore. Since 

, CPython artifacts have been signed with both PGP and Sigstore. PGP relies on long-lived private keys, which release managers must maintain and protect for many years, creating ongoing risks and burdens. In contrast, Sigstore uses short-lived keys tied to human-readable identities via OpenID Connect, greatly simplifying the signing process while providing stronger ergonomics. Sigstore is already gaining wide adoption across ecosystems like PyPI, NPM, Homebrew, and GitHub.

This new feature will not only deprecate, but will eventually discontinue the PGP signatures for CPython altogether, transitioning fully to Sigstore. Current stable releases (3.11 through 3.13) will continue offering PGP signatures until end-of-life, but new release managers (starting with Python 3.14) will not be required to generate them. Maintaining dual systems has slowed adoption of newer methods, creating a “

” that discourages verifiers from moving forward.

By dropping PGP, CPython can encourage downstream ecosystems to fully adopt Sigstore, while still providing flexibility for extraordinary delays if needed. Though this change shifts reliance to Sigstore’s centralised infrastructure, it aligns with the security practices already expected of release managers and leverages services better suited for long-term key management. Documentation will guide integrators, such as Linux distros and package managers, on verifying artifacts with Sigstore.

Disallow return/break/continue that exit a finally block

Python 3.14 – What you need to know 

 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

 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, 

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

More articles

Kubernetes 1.35 – What you need to know

Python 3.14 – What you need to know

Migrating from Docker Content Trust to Sigstore

Kubernetes 1.34 – What you need to know

Adding AI to applications using the Model Context Protocol

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