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.

 - Since tools may trigger arbitrary code execution, hosts must treat them with caution and verify trust. Descriptions alone should not be trusted unless verified, and execution must be explicitly authorized.

 - Any use of LLM sampling must be user-approved. Users should be able to control whether sampling occurs, what prompt is sent, and what response visibility the server has.

MCP is unable to enforce these security principles; that is the responsibility of developers. And as a rule, they should follow these guidelines as outlined in the MCP spec:

The application should use robust flows for consent and authorization

All security implications must clearly be outlined in documentation

Appropriate access controls and data protection must be in place

Follow all security best practices when building integrations

When designing features, always consider privacy implications

Some diligence is required to ensure appropriate security controls are in place.

Expose tooling and capabilities to AI systems

Build modular integrations, composed of task-specific capabilities (such as retrieving metadata, or querying an audit log) that can be chained into larger, reusable workflows

Approach data security within your infrastructure

These attributes and Anthropic’s credentials have seen it quickly gain traction. Despite its release in 2024, MCP is becoming an industry standard and is now 

Cloudsmith has built a prototype MCP server as a step towards LLM and AI agent interaction with the artifacts and data in your Cloudsmith workspace. This could radically transform how you can control your software supply chain. It would replace potentially time-consuming command-line or UI workflows and provide fast and intuitive control with natural language prompts.

For example, ask questions like “List all versions of a particular library in Cloudsmith.”, “Tell me how many packages I have in Cloudsmith with a high CVE or that would violate a certain policy.”, or “If I reduce retention from 90 to 30 days, what will be deleted? How will that impact my allowances?”.

The image below shows an example from our proof-of-concept MCP server Claude integration. We asked, “What repository contains the Ubuntu 14.04 Docker image?”

Cloudsmith is in the early stages of this research, but our initial prototype is showing huge promise. For more information and examples, see 

MCP clearly represents an exciting opportunity for application developers to plug into AI in a scalable and economical way. Cloudsmith has started this journey with our MCP server. DevOps and developer teams will soon be able to use intelligent agents to automate, assist, or enhance their artifact management and software supply chain workflows. This is potentially transformative and may well become the future of artifact management.

If you'd like to register for early access to the Cloudsmith MCP server, 

Ian Taylor

Tech Content Director

Adding AI to applications using the Model Context Protocol

This blog contains the takeaways from our webinar "State of the Union: Modern security approaches for the Software Supply Chain." Watch the full discussion 

. Key topics include how to secure your CI/CD pipeline and software artifacts using SBOMs, Docker Hardened Images, and artifact lifecycle best practices.

Software supply chain attacks are on the rise, prompting a critical shift in how we secure modern software. Recent incidents like SolarWinds, XZ Utils, and Log4Shell underscore the urgent need for stronger security measures beyond just protecting production systems. Attackers are now targeting earlier stages of the supply chain, particularly build pipelines, impacting software integrity before it even reaches deployment.

State of the Union: Modern security approaches for the Software Supply Chain

 we brought together industry experts to tackle these challenges head-on. Michael Donovan, VP of Product at Docker, Ralph McTeggart, Principal Engineer at Cloudsmith, and Jack Gibson, Senior Software Engineer at Cloudsmith, shared their insights on how leading teams can defend themselves. During the session, they explored the evolving threat landscape, outlined a secure artifact lifecycle, and discussed strategies such as SBOMs to inject visibility, provenance, and trust into workflows without creating developer friction. While the focus was on container images, the principles discussed were equally applicable to other formats.

Rethinking Software Supply Chain Security

Software supply chain attacks have grown dramatically in both frequency and impact, prompting a fundamental shift in how software is secured. Incidents like SolarWinds, the XZ Utils backdoor attempt, and Log4Shell illustrate a sobering truth: attackers are now aiming upstream. Rather than targeting production systems directly, modern threats exploit vulnerabilities during the software build and integration phases, where visibility and control are often weakest.

As this attack surface expands, it’s no longer enough to harden runtime environments or secure production endpoints. The entire artifact lifecycle - from development to deployment - must be secured. This shift has led organizations to reassess their tooling, processes, and practices around software composition, packaging, and distribution.

The Shift in Emphasis on Software Supply Chain Security

The strategic focus of software security has moved upstream. Major breaches have shown how attackers exploit weaknesses in CI/CD pipelines, source code repositories, and registry infrastructure, areas traditionally outside the purview of security teams.

Events like the SolarWinds compromise in 2020, which leveraged a poisoned build system, or the 2024 XZ Utils incident, where malicious code was inserted by a fake maintainer, underscore how early-stage compromises can lead to widespread downstream impacts. Similarly, Log4Shell revealed the global exposure caused by a single vulnerable dependency, forcing organizations to redirect substantial resources just to locate and patch affected systems.

In response, governments and regulatory bodies have escalated their focus on software supply chain security (SSCS). Executive directives, such as the U.S. Cybersecurity Executive Order, FedRAMP requirements, the EU’s NIS2 directive, and the forthcoming Cyber Resilience Act, demand secure development practices, transparent artifact composition, and provable software provenance.

As attacks increasingly originate at the source, securing the artifact lifecycle is now a foundational requirement - not a future goal.

Modern software development is built around composability and speed. Applications today rely heavily on third-party libraries and frameworks, with open-source components making up as much as 75% or more of a typical codebase. The prevalence of transitive dependencies - indirect libraries brought in through direct ones - adds complexity and opacity to risk assessment.

At the same time, the efficiency of CI/CD pipelines can leave little room for traditional gatekeeping. Code is integrated, tested, and deployed rapidly, often using packages pulled directly from public registries with minimal verification. Unsigned artifacts, missing provenance data, and outdated registry configurations persist across many organizations.

This environment creates ideal conditions for silent, hard-to-detect supply chain threats. In response, software teams must move toward practices that ensure transparency, verification, and control at every phase of the build and release cycle.

Using SBOMs and Establishing Provenance

A foundational step in securing the software supply chain is understanding exactly what is being built and shipped. This is where three elements play a critical role:

SBOMs (Software Bills of Materials): These list all components within a software artifact - names, versions, authors, licenses, and dependency relationships. Tools such as Syft and Trivy support SBOM generation in SPDX and CycloneDX formats. Docker supports SBOMs natively through the docker sbom command. Cloudsmith accepts external SBOM uploads or can auto-generate CycloneDX SBOMs for container images, exposing them via API for automation and policy enforcement.

Digital Signatures: A signature confirms that an artifact originated from a known and trusted source. Tools like Cosign allow developers to sign and verify containers. Signed images enable downstream consumers to confirm authenticity before deployment.

Provenance: Provenance data describes the origin of a build, including input sources, build parameters, and environments. Docker Buildx supports automated provenance generation using the --provenance flag, capturing crucial metadata such as build arguments and platforms.

Together, these elements create an auditable trail of software origin and composition. In regulatory contexts, SBOMs are now a standard requirement. But beyond compliance, they provide security teams with the ability to trace vulnerabilities to specific packages, drastically reducing remediation time and effort. Cloudsmith’s Enterprise Policy Management (EPM) leverages SBOM metadata for automated policy actions, such as quarantining risky images or enforcing license compliance based on live dependency data

Tightening Security with Docker Hardened Images

As organizations grapple with securing sprawling software pipelines, Docker Hardened Images (DHIs) offer a straightforward way to integrate trusted, verifiable container artifacts into modern workflows, without slowing down development.

Available on Docker Hub, DHIs are a curated set of container images designed to minimize vulnerabilities out of the box. They are built with a smaller attack surface, and include a full suite of embedded security metadata by default. This makes them ideal for teams looking to adopt zero-trust practices without adding complexity or friction.

VEX (Vulnerability Exploitability eXchange) metadata

These attestations provide comprehensive visibility into the contents and origin of each image. Because they are packaged directly with the artifact, they integrate seamlessly into downstream platforms like Cloudsmith or any private registry. This removes the burden of generating and attaching this metadata later in the pipeline.

The impact is significant: DHIs can reduce vulnerabilities in base images by as much as 95%, offering a hardened starting point for secure application builds. Just as importantly, they help teams meet compliance and audit requirements from day one, with verifiable transparency and traceability.

By building security directly into the image and surfacing critical metadata in machine-readable formats, Docker Hardened Images simplify the process of building secure containers—and make modern supply chain security accessible by default.

Building a Secure Artifact Lifecycle

A secure software supply chain requires continuous validation from development through delivery. This is where centralized artifact management platforms like Cloudsmith become essential.

By configuring repositories to proxy public registries (e.g., Docker Hub, NPM, PyPI), Cloudsmith performs key security checks automatically:

Artifacts are cached and versioned, offering security and development teams full visibility and control over dependencies. When an image is pulled, verification steps - including signature checks and attestation validation - ensure that only known, trusted, and reproducible software is admitted into builds or deployments.

However, the ecosystem still faces gaps. Many widely used packages, particularly in NPM and PyPI, lack signatures or attestations. As of late 2024, only 5% of the top 360 packages on PyPI had provenance data published through the trusted publisher workflow. This makes it difficult to assert origin or integrity for many upstream dependencies.

To address this, teams should introduce a secure intermediary - like Cloudsmith - between developers and public sources. This provides enforcement points for policy, visibility into dependencies, and the opportunity to filter and block unverified packages before they can compromise the build.

Once builds are finalized, signing them and recording those signatures in transparency logs (e.g., Sigstore’s Rekor) ensures traceability and trust. This final step solidifies confidence that artifacts were not tampered with before reaching production.

Security features must be accessible, automated, and non-disruptive to gain widespread adoption. Teams are more likely to maintain best practices when secure workflows mirror familiar development patterns.

 come pre-equipped with SBOMs, digital signatures, and SLSA-compliant provenance. These attributes allow teams to build secure pipelines without requiring additional tooling or custom scripting.

When paired with Cloudsmith, this enables organizations to:

Centrally manage and enforce policies on all artifacts

Control access and visibility across engineering teams

Integrate security checks without altering development velocity

The result is a zero-trust pipeline where software integrity is maintained automatically, and security is treated as a first-class concern throughout the SDLC.

The shift towards modern security approaches is undeniable. SBOMs, signatures, and attestations are becoming fundamental elements in software development. The impending legislation, particularly in the EU with the Cyber Resilience Act, will further mandate these practices.

For a deeper dive into securing your container workflows, check out our companion blog post, "

Securing Containers at Scale: Docker Hardened Images and Cloudsmith

Maia Livingstone

Campaign Manager

Jack Gibson

Senior Software Engineer

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

Pulling Docker images from private registries for containerised applications presents a security challenge. It requires authentication management, network access, and trust across distributed systems. Credentials must be securely handled and rotated, and image pulls can break due to network restrictions or expired tokens. All of this makes deployment and security harder.

To address this, you can use OpenID Connect (OIDC) when pulling Docker images from Cloudsmith into Kubernetes. OIDC adds a layer to OAuth 2.0 that identifies who is making the request. Cloudsmith can then verify that the requests come from a trusted source and can grant short-lived access tokens. So you no longer have to rely on long-lived credentials, enhancing security and simplifying credential management.

Kubernetes clusters often need to pull Docker images from private registries like Cloudsmith. Traditionally, this meant storing long-lived credentials in the cluster, which has some security risks:

Credentials could be compromised if the cluster is breached.

Regular rotation of credentials becomes a manual, error-prone process.

It's hard to apply the principle of least privilege effectively.

Before we dive into the solution, let's review what an Image Pull Secret is in Kubernetes.

An Image Pull Secret is a way to pass credentials to the kubelet to authenticate with a private container registry. Typically, the secret contains:

While Image Pull Secrets solves the immediate authentication problem, using them with long-lived credentials still exposes us to the security risks mentioned earlier. The credentials don’t automatically expire, leaving them vulnerable to misuse if leaked or unrotated.

OpenID Connect (OIDC) allows us to use short-lived tokens instead of long-lived credentials, reducing risk exposure. Here's how it works in the context of Kubernetes and Cloudsmith:

Kubernetes has its own identity in the form of a service account. The service account has an associated JWT (JSON Web Token). During runtime, the following steps are taken:

Kubernetes issues the signed OIDC token (a JWT).

Cloudsmith receives and verifies the JWT and exchanges it for a short-lived Cloudsmith token.

Kubernetes uses the short-lived Cloudsmith token to create or update an Image Pull Secret.

At runtime, the pod requests to pull an image.

Kubernetes pulls an image from Cloudsmith using the Image Pull Secret for authentication.

To automate the process, we use a Kubernetes CronJob. This job runs at regular intervals and performs the following tasks:

Retrieves the Kubernetes service account token.

Exchange service account token for a Cloudsmith token via OIDC.

Create or update an Image Pull Secret with the new Cloudsmith token.

Here's an example of what this CronJob might look like:

2. Gets the Kubernetes service account token.

4. Creates or updates an Image Pull Secret named cloudsmith-pull-secret.

Implementing this OIDC-based solution offers significant benefits:

: The CronJob ensures the token is regularly refreshed, maintaining a good security posture without manual intervention.

: There's no need to manually update credentials, reducing operational overhead.

: The token only has the permissions it needs for a limited time, aligning with security best practices.

Once the Image Pull Secret is created or updated by the CronJob, you can use it in your pod specifications like this:

This pod will use the cloudsmith-pull-secret to authenticate with Cloudsmith and pull the specified image.

Using OIDC to pull Docker images from Cloudsmith into Kubernetes eliminates the need for long-lived credentials. It reduces the risk of leaked credentials, removes the need for manual credential rotation, and aligns with current security best practices.

Authentication in Kubernetes is evolving with significant recent enhancements. Kubernetes v1.20 saw the introduction of 

. These allow the kubelet to dynamically request credentials for a container registry instead of storing static credentials on disk. This was enhanced in v1.33 to support automatic use of the service account token for image pulls. This enables short-lived authentication without needing to manage Image Pull Secrets and reduces complexity. Cloudsmith remains vigilant, and these updates help with our goal of increasing automation in supply chain security.

Ian Duffy

Site Reliability Engineer

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

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.

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

 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 64 Enhancements in all listed within the 

Kubernetes 1.33 brings a whole bunch of useful enhancements, including 35 changes tracked as ‘

’ in this Kubernetes release. From these, 

 are graduating to stable, including the ability to specify a new 

 commands like get, patch, edit and replace commands, which provides a new way to allow fetching and updating of subresources like status, scale, and more.

 features are also listed in the enhancements tracker, with a bit of conversation at Kubecon Europe around the ability to implement declarative validation of Kubernetes native types using 

 to generate validation code. Amongst other benefits, DevOps teams will benefit from streaming encoding specifically for LIST response. This enhancement significantly reduces memory consump

tion on the API Server when serving large LIST responses.

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.33.

Here are a few of the changes that Cloudsmith employees are most exciting for in this release:

The current approach to deleting resources within a Kubernetes namespace is somewhat flawed, especially in environments that demand strict security controls. Relying on a semi-random deletion order introduces unnecessary risk. One particularly dangerous scenario is when a Pod outlives its associated NetworkPolicy, effectively stripping it of its intended network protections and leaving it wide open to unrestricted access. This creates a serious risk.

To address this, the Kubernetes maintainers proposed a deliberate and opinionated deletion strategy that prioritises security by enforcing a logical order: Pods should be deleted before their dependent resources, like NetworkPolicies. This isn’t just about order, it’s about responsibility. By acknowledging some real-world implications of resource dependencies and acting accordingly, you can dramatically reduce the chance of exposing workloads during namespace teardown.

Nigel Douglas – Head of Developer Relations

What excites me most is the long-anticipated improvement around support for user-specific namespaces. This feature would allow our teams to better isolate security-sensitive elements such as user and group IDs, root directories, capabilities, and encryption keys. User namespaces offer a way to differentiate identity and permissions inside a container from those on the host system. We’re looking to avoid scenarios where a process could operate with full privileges (user ID 0) within its namespace while remaining an unprivileged user outside of it.

Bringing user namespace support to Kubernetes would enable pods to run with distinct user and group IDs compared to the host. This means a process that appears privileged inside the container is effectively limited in scope if it escapes to the host, reducing our risk of a system-wide compromise. It's a powerful security boundary that can help contain potential breaches and enforce least privilege at runtime.

I'm especially pleased to see the introduction of in-place updates for Pod resource requests and limits, eliminating the need to restart Pods or their Containers. Adjusting resource allocations can become necessary for a number of reasons, whether due to a spike in workload, under-utilisation of assigned resources, or simply because the initial settings were misconfigured.

Until now, modifying a Pod's resource configuration required a full restart, as the resource fields in the PodSpec are immutable. While this may be manageable for resilient, stateless applications, it poses a challenge for workloads that are stateful, batch-oriented, or run with minimal replicas. In such cases, restarting Pods can lead to unnecessary downtime or increased operational costs. The ability to adjust resources dynamically, without disruption, is a valuable improvement that directly improves availability.

It’s important to note, however, that while these resource values can now be updated in place, the Pod’s Quality of Service (QoS) class remains immutable. This is a key consideration because the QoS classes (

) - is determined at Pod creation based on the presence and nature of resource requests and limits. Since the QoS class influences how Kubernetes schedules and evicts Pods under resource pressure, it’s crucial to set these values thoughtfully at the outset.

For example, you might increase a Pod’s CPU and memory limits significantly using an in-place update, but if the Pod was initially classified as 

, Kubernetes may still deem it a lower priority and evict it during contention, even though it's now consuming a large share of resources. This kind of mismatch can lead to surprising and frustrating behaviour in production, which is why understanding the fixed nature of QoS classes is just as important as the flexibility offered by in-place updates.

In the current Kubernetes implementation, all indexes within an indexed job share a single backoff limit. This means if the overall job hits that limit, the entire job is marked as failed, even if some indexes haven't finished running. This model doesn't align well with embarrassingly parallel workloads, where each index operates independently. For example, using indexed jobs for a suite of long-running integration tests would halt all tests after a single failure, limiting visibility into other potential issues. In contrast, systems like 

 already treat each index separately, highlighting the need for a more flexible approach in Kubernetes.

To address this, the proposal introduces a per-index backoff policy, allowing each index to fail or succeed independently. This would let jobs continue running even if some indexes fail. It also suggests a new API field to control the number of allowed failed indexes, and a new FailIndex action within the 

 to proactively stop retries for specific indexes before hitting the backoff limit.

Some batch workloads, such as those using MPI or PyTorch, only rely on specific "

" indexes to determine whether a job has succeeded. However, the current Kubernetes behaviour requires all indexes in an indexed job to succeed before the job is marked as complete, which limits flexibility for these use cases. To address this, a proposed extension to the Job API introduces a configurable success policy, allowing users to define custom conditions under which an indexed job can be considered successful.

With this enhancement, a job can be marked as succeeded based on specific criteria - for example, if certain indexes [0, 1, 2] complete successfully, or if a minimum number of indexes succeed. Once the job meets the defined 

, any remaining pods are terminated, avoiding unnecessary resource consumption. This proposal does not alter the behaviour of jobs that don’t use a 

, nor does it apply to non-indexed jobs at this time, as those scenarios currently lack strong use cases. A new condition, 

, will indicate when a job satisfies its defined success policy.

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 - which can cause resource strain, potential scheduling issues, and even unnecessary autoscaling, which also may increase cloud costs in large-scale or tightly resourced environments.

A key long-term goal for improving Kubernetes usability is to shift validation logic from controllers to the front-end. Currently, the handling of validation for unchanged fields presents a barrier for both Custom Resource Definition (

) authors and Kubernetes developers, preventing broader adoption of validation features. CRD authors face difficulties when modifying value validations, as they must increment the version even for minor changes, which can be cumbersome and disrupt the user workflow.

This proposal aims to eliminate barriers that hinder CRD authors and Kubernetes from adjusting value validations. By removing these obstacles, CRD authors can more easily widen or tighten value validations without fear of breaking workflows. The goal is to automate this process for all CRDs installed into clusters with the feature enabled, ensuring minimal overhead-negligible persistent overhead and up to a 5% time overhead for resource writes. The approach also emphasises correctness by ensuring that invalid values, which would fail a known schema, are not allowed.


This proposal introduces a more secure leader election mechanism for component upgrades and rollbacks, primarily leveraging leases with two significant changes. First, instead of competing for the lease, component instances declare their candidacy, and an election coordinator selects the best candidate by choosing the one with the lowest version, ensuring skew rules are upheld. Second, the election coordinator can mark a lease as "

" which prompts the current leader to stop renewing the lease and allows the coordinator to replace it with a better-suited leader. This approach addresses the issues that arise during node-by-node upgrades and rollbacks in systems like Kubernetes, Cluster API, kubeadm, and KIND, which often lead to skew violations due to timing inconsistencies in component upgrades.

The proposed mechanism aims to resolve challenges such as the potential for skew violations when a new version of a controller runs while old versions of the API server are still active. It also prevents lease loss during upgrades or rollbacks, which can cause component version flip-flopping. The goal is to enable more predictable version changes, avoid skew violations, and ensure a smoother upgrade process while allowing for canary deployments or pauses during upgrades. This enhancement, when combined with other tools like 

, improves the ability to manage control plane components during upgrades, rollbacks, and downgrades. The proposed solution offers an opt-in mechanism to elect the oldest version candidate and preempt the current leader, reusing the existing lease structure as much as possible.


This proposal introduces an opinionated deletion process for Kubernetes 

 to ensure secure and predictable removal of resources. Currently, the deletion order is semi-random, which can result in security gaps, such as Pods remaining active after their associated NetworkPolicies have been deleted. By implementing a more structured deletion order, Pods will be deleted before other resources based on logical and security dependencies, improving both security and reliability. This change addresses risks caused by non-deterministic deletion and ensures the safe termination of resources in a more controlled manner.

The current random deletion process poses significant challenges, especially in security-sensitive environments. For example, deleting a 

 before its associated Pod can expose the Pod to unrestricted network access, creating a security vulnerability. The proposed opinionated 

deletion process aims to enhance security by ensuring that resources like NetworkPolicies remain active until all dependent resources are properly terminated. Additionally, it provides a more predictable and consistent cleanup process, reducing operational disruptions. The proposal also maintains compatibility with existing Kubernetes workflows and APIs while ensuring safe and reliable resource cleanup.

Currently, working with sub-resources such as 

 in Kubernetes through kubectl is a cumbersome process. Users must rely on 

 to fetch sub-resources, and updating them (like patching the 

) requires resorting to direct curl calls against the API server. This workflow is far from intuitive and creates unnecessary friction for developers and operators when testing, debugging, or interacting with the Kubernetes API.

To improve this experience, a proposed enhancement introduces a new 

. This change makes subresources like status, scale, and resize accessible and manageable across all supported resource types, including custom resources. When using the new flag, subresource outputs will be formatted consistently with the main resource view, ensuring clarity and usability. It's important to note that the subresource API behaves the same as the full resource, so changes, like updating the status, may still be subject to reconciliation by the corresponding controller.


 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.

Using GitHub Actions to push packages to Cloudsmith

More articles

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

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Kubernetes 1.33 – What you need to know

Integrating Dependabot with Cloudsmith Using OIDC