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

Yet another supply chain attack has surfaced, this time using the xrpl library to sneak through malicious packages. 

 is recognised as the recommended npm library for integrating the 

 with JavaScript/TypeScript applications, and has over 140k downloads a week.

Our security team quickly responded to this threat and found that no Cloudsmith customers are currently using any of the affected versions.

The attack strategy was to introduce five suspect versions of the library, masquerading as genuine releases. They inserted a crypto-stealing backdoor by adding malicious code that could leak private keys and silently sign fraudulent transactions.

npmjs have recently released version 4.2.5, which overrides the compromised versions.

 can get a full and detailed description of the attack from Charlie Eriksen at 

XRP supply chain attack: Official NPM package infected with crypto stealing backdoor.

The vulnerability is logged with the CVE Dictionary Entry of 

XRPL Dependencies - A Critical Security Risk

The XRPL is a Layer 1 blockchain built for payments and asset transfers. Layer 1 blockchain is the foundational infrastructure of a blockchain. This is where core functions are handled, such as validating transactions, securing the network, and ensuring consensus around transactions and ownership.

The XRPL is used by financial institutions, fintech companies, developers, and startups, mostly for payments, asset tokenization, and building lightweight financial applications.

A supply chain attack on a package integrating with the XRPL can have serious implications. It could expose private keys, hijack transactions, or leak sensitive data, without compromising the ledger itself. If xrpl.js is compromised, any apps using it could unknowingly sign malicious transactions or leak user information, which could result in stolen funds. XRPL dependencies are critical to security.

Any security features can and should be tested against real-world threats. Cloudsmith’s Enterprise Policy Management (EPM) includes policy-as-code, meaning custom policies can be written against precise requirements to block known exploits.

For the xrpl.js attack, we know the bogus versions, so it’s easy to write Rego code that checks your repository against the known versions. Cloudsmith can then quarantine the packages if there’s a match against npm packages named xrpl:

 information on setting up and configuring policy code, see 

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

smith and see how it can stop supply chain attacks.

Ian Taylor

Tech Content Director

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

Enterprise Policy Management (EPM) is a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain. Teams can codify rules once and apply them continuously across repositories. With Cloudsmith’s platform, organizations extend policy enforcement across teams, environments, and geographies without introducing friction, including the open source packages that the chain depends on.

Our EPM solution is powered by data at every stage. The policy engine has access to all available package metadata to inform decisions. Every policy action is recorded with full context, providing detailed logs for customers to support audits and investigations. EPM includes compliance dashboards, that surface insights in security, compliance, and policy activity. This gives you continuous oversight and helps you refine your approach.

This article provides an overview of EPM and how it strengthens the software supply chain. For a worked example using policy as code, see 

We built EPM because governance should not slow you down; it should accelerate trust. Threats to your software supply chain are evolving faster than human oversight can track, and automation is the only viable path to resilience. EPM puts policy enforcement early in the development process. It makes decisions transparent and implements your security and compliance posture into something repeatable, testable, and version-controlled, like the rest of your codebase. Developers get immediate insight to help select packages. They know which meet policy standards for security, licensing, and quality.

Policies are codified rules that automate decisions and enforce rules on which packages are allowed in your software supply chain. They provide guardrails that ensure security, compliance, and operational consistency. Policies can block vulnerable packages, restrict problematic licenses, and control access.

For example, an enterprise may add a policy that stops packages with high-risk vulnerabilities from reaching production environments. The policy would be prescribed by logic as follows:

Define logic that evaluates vulnerability criteria and applies a quarantine action to affected packages.

The criteria specifies that the vulnerability must be listed in the Common Vulnerabilities and Exposures (CVE) database.

The policy then checks if the vulnerability exceeds a defined 

If conditions are met, the package can either be quarantined and blocked from promotion to production or tagged with additional context for further forensics.

This previous example is a vulnerability policy and is one of the types Cloudsmith EPM supports:

 prevent non-compliant code from being used.

 automate tagging, quarantining, or deleting based on metadata.

Without strong policy management, teams face increased risk and unnecessary effort:

- Missing automation allows known CVEs or malicious packages to reach production.

 - Teams must scramble for audits instead of demonstrating continuous compliance.

- Engineers spend hours reviewing dependencies or waiting for late-stage approvals.

Without shared policies, standards vary across teams and environments.

Without codified policies, organizations cannot fully benefit from the scale and speed of the cloud.

Catching vulnerabilities early in the software delivery lifecycle reduces both the financial cost of remediation and the risk of reputational damage.

EPM was built to avoid these issues in response to real-world supply chain threats and close collaboration with our customers. Codification and automation provide a unified approach for teams to enforce decisions that were previously enforced manually and inconsistently, proving less robust or scalable.

In an automated delivery environment, policies are essential for reducing manual overhead, preventing costly mistakes, and proving compliance, and have particular relevance within the organization:

-For CISOs, policies are the cornerstone of a secure software supply chain. They enable proactive threat mitigation, enforce compliance with frameworks like SLSA and SC2CF, and provide the audit trails required for regulatory confidence. Cloudsmith’s EPM lets CISOs shift from just enforcing checklists to actively collaborating with engineering teams by using the same tools. Implementing automated policies makes it easier for the engineering team to build securely.

- CTOs are focused on enabling product velocity without compromising architectural integrity. Effective policy management acts as a safeguard for CTOs, giving them confidence to move fast with greater safety, supporting both innovation and security goals. With EPM, they can align engineering output with business goals, ensure consistent implementation of best practices, and reduce the operational burden of manual reviews.

Teams immediately benefit by switching from public repositories to Cloudsmith as a curated repository for their developers. Policies then provide clarity, speed, and safety for engineering teams. Instead of guessing what is allowed, developers get immediate feedback when a package or dependency violates a rule. Our EPM integrates policy checks directly into the artifact pipeline, shifting decision-making left and reducing the noise and frustration caused by late-stage security reviews. 

EPM: Cloudsmith’s Approach to Policy Management

Maximum Flexibility: Policy-As-Code, Open Policy Agent, and Rego

Cloudsmith builds for developers, and EPM continues that focus by applying code's flexibility and automation to policy management. EPM takes a policy-as-code approach using an engine built on codification to make policies flexible, versioned, testable, and part of the everyday development workflow. It uses repeatable logic and brings security and compliance into the same toolchain engineers already use.

 - Teams write policies in Rego to define clear, actionable rules that operate on artifact metadata, repository structure, and scan data. We chose 

 because it is an established, open-source policy language widely used in infrastructure and platform security. Rego allows teams to write expressive, testable rules and reason over structured data, which aligns with how Cloudsmith models package metadata and security inputs.

 OPA is a general-purpose policy engine that evaluates rules written in Rego. Cloudsmith integrates OPA into its EPM engine to provide a programmable, scalable way to enforce policy across artifacts. Because OPA is already well established in platform tooling like Kubernetes and Terraform, teams can manage policies in a format they know and trust, without switching tools or inventing new processes.

- EPM also offers key features through the Cloudsmith UI. This supports essential policy management controls, letting users operate EPM without the need to dive into policy-as-code.

You can see an example of the Rego code used to implement the policy given in Vulnerability Policy Example above.

Cloudsmith’s policy engine lets you create and automate vulnerability policies to an exact specification. Policies evaluate packages as they arrive and apply structured logic to make decisions based on severity, exploitability, and metadata. We made package data available so you have the information to tailor and align your policies to the datasets that matter most.

The following capabilities form the foundation of Cloudsmith’s approach to automated vulnerability policies:

Vulnerability Management & Dependency Awareness

 - EPM scans artifacts continuously and examines both the dependencies developers choose directly and the ones that come bundled with them. This helps teams understand the full scope of their exposure, especially when vulnerabilities are introduced through nested packages or upstream registries.

 - CVSS scores represent how severe a vulnerability is, while EPSS scores estimate how likely it is to be exploited in the real world. Cloudsmith supports both scoring systems to help teams write policies that prioritize the vulnerabilities that pose the highest risk.
See 

Cloudsmith introduces EPSS Scoring in Enterprise Policy Management

 - Teams can preview how a policy will behave before activating it. This reduces the risk of unintended disruption and helps refine logic before activation. Once a policy is active, EPM logs each decision, making actions traceable and audit-ready.

EPM continues to evolve, and we’re expanding the scope of what policies can evaluate. This includes extending scanning to third-party sources like OpenSSF Scorecards. We’re enriching package metadata with contextual signals, giving policies a broader view to make more accurate decisions.

Legal teams and engineering organizations need to manage license risk at scale. Cloudsmith EPM allows teams to define precise rules about which licenses are permitted, restricted, or prohibited across repositories and environments. Policies can block packages with unknown, copyleft, or non-compliant licenses before they are introduced into critical environments. These rules operate on package metadata and are enforced automatically at sync, ensuring consistent application across teams and projects.

EPM license management includes the following key capabilities:

 - Packages with prohibited licenses are blocked by codifying license rules into policy logic. These policies evaluate license metadata before packages reach environments where risk cannot be tolerated, such as production environments or regulated systems.

 -Policies can reflect both internal legal requirements and external compliance frameworks. Teams can author policies that support organization-specific license strategies while aligning with broader standards such as SPDX or OpenChain.

Manage Internal Remediation SLAs with Time-Based Policies

Time-based policies help teams manage the lifecycle of packages based on changing risk, review cycles, or policy timing. These policies allow organizations to enforce rules that adapt over time, such as delaying access to a package until it has passed a minimum review period or increasing enforcement if a vulnerability remains unaddressed beyond a defined threshold.

EPM’s time-based policy management includes CVE lifecycle enforcement. A policy can allow packages with a known high severity CVE to remain in a non-production repository for a defined period. If no fix is applied during that window, the policy escalates enforcement by blocking promotion, triggering quarantine, or flagging the package for remediation. This gives teams time to assess and respond while maintaining clear accountability and control.

We’re extending policy capabilities to increase support for time-based controls. This includes defining policies that delay promotion, trigger re-evaluation, or expire package access after a specific time window. This will support workflows like phased rollouts, cooling-off periods, or automatic clean-up of outdated packages.

Cloudsmith EPM allows teams to define precise policies in line with their organization’s compliance requirements. These examples reflect common use cases in vulnerability management, license enforcement, and exploitability scoring.

Time and Score Balanced CVE Remediation Policies

Customers can use EPM to build policies that align with their organisation’s internal CVE remediation timelines or industry best practices. Policies could escalate enforcement based on how long a CVE has gone unpatched.

For example, quarantine any package that has a:

CVE with a CVSS score of 9 or more that was reported 7 or more days ago.

CVE with a CVSS score of more than 7 that was reported 30 or more days ago.

CVE with a CVSS score of more than 4 that was reported 60 or more days ago.

Customers can use EPM to control which software licenses are permitted in their environments. Many organizations prevent the use of copyleft licenses because these licenses can require proprietary source code to be made public. Copyleft licenses, such as the GNU General Public License (GPL), impose obligations that conflict with closed development. Teams often prefer permissive licenses such as MIT, Apache, or BSD to minimize legal risk.

Quarantine any package that carries a GNU General Public License (GPL).

Quarantine any GPL-licensed package found in production repositories, with the highest legal exposure.

Customers can strengthen their vulnerability management by using the 

Exploit Prediction Scoring System (EPSS) 

as an additional prioritization tool. EPSS provides a daily probability estimate for the likelihood of a CVE being exploited in the wild. This helps teams move beyond severity alone and focus remediation efforts on the vulnerabilities most likely to be targeted.

Quarantine any package containing a CVE with an EPSS score of 0.2 or more.

EPM: Policy Management for the Vigilant Enterprise

Software governance is an operational necessity. Cloudsmith EPM provides a programmable layer that helps teams codify their organization's vision for secure and compliant software and then enforces those standards automatically.

By aligning security, legal, and engineering teams around shared, automated rules, EPM removes friction and gives control, making governance part of the pipeline.

To discover how EPM can solve your policy management needs, 

Enterprise Policy Management with 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 ‘

 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.

 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


Cloudsmith Blog

Kubernetes 1.34 – What you need to know

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

Enterprise Policy Management with Cloudsmith

Kubernetes 1.33 – What you need to know

KubeCon London 2025 Recap: Cloud-Native Insights on Security, Wasm, and More