By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

Every container inherits its base image. If that image carries unpatched CVEs, your application does too – before you've written a line of code. Hardened images fix the baseline: compiled from source with SLA-backed patching that keeps them clean after day one.

Distribution of these hardened images becomes a challenge. Security teams can pick a better image source, but making that image the default for every developer and build agent means new registry credentials per team and changes to how they pull. Adoption rollout becomes its own project, and it compounds across every team building containers. That's where adoption stalls.

 and Cloudsmith address the security and distribution aspects of using hardened images. WizOS compiles hardened container base images from source in an auditable pipeline, backed by strict remediation SLAs and cryptographic provenance. Cloudsmith puts those images behind the registry URL your teams already use, authenticated with credentials they already have.

Wiz doesn't pull pre-built packages from upstream public repos and assemble them. Wiz compiles its WizOS images from source in a controlled, auditable pipeline they own. You benefit from strict remediation SLAs that guarantee near-zero CVEs: 7 days for criticals, 14 days for highs and mediums. These builds also produce cryptographically verifiable provenance and signatures, so you can confirm exactly what shipped and where it originated. WizOS images have a minimal footprint, using only the components an image actually needs and 

 for broad compatibility with existing applications.

Hardened images writ large have the same goal: trust a maintained baseline instead of public open source upstreams. Wiz backs its WizOS hardened images with its own vulnerability and runtime data.

Cloudsmith treats the WizOS Registry like any other upstream (e.g., Docker Hub, npm, PyPI), as a source you proxy and cache behind your existing Cloudsmith repository URL. Developers don’t need to change how they pull images.

 In your Cloudsmith repository's Upstream Proxying settings, create a new Docker-format upstream pointing at 

, set your priority, and choose Cache and Proxy.

. Grab your Wiz Registry credentials from your WizOS tenant (Profile > Tenant Info > Wiz Registry Credentials) and configure them on the upstream. From here, Cloudsmith handles authentication on behalf of every developer and build agent, so nobody else needs a WizOS login.

 and pull images using their existing Cloudsmith repository path, for example:

Cloudsmith resolves the image, caches it on the first pull, and serves it from Cloudsmith's edge network on every subsequent pull.

Once you configure WizOS in Cloudsmith the one remaining manual step, 

, becomes optional. The Cloudsmith CLI's new Docker credential helper (added in 

) lets Docker authenticate to Cloudsmith registries automatically, using credentials your CLI already has.

 against your Cloudsmith registries, WizOS included, just work. You don’t need to worry about a login step, copying a token into CI secrets, or risk having credentials sitting in a config file that can expire or leak.

The helper also discovers any custom Cloudsmith registry domains on your account via the API and caches them locally, so it isn't limited to the default 

 host. If you need to point it at additional hostnames, pass 

 to preview what it would change before it changes anything; and skip the auto-discovery step with 

 if you'd rather manage the domain list yourself. When you need to back the help out, 

cloudsmith credential-helper uninstall docker

The Cloudsmith credential helper gives you one line in your provisioning script for all your build agents instead of a 

 call (and a credential) in every pipeline.

What the WizOS/Cloudsmith combination gives you is a pattern, not just a configuration. Your WizOS credentials live in Cloudsmith's upstream config once. No developer or build agent ever handles them directly. The credential helper removes the last manual authentication step, so pipelines authenticate using CLI credentials they already have. The initial base image pull caches in Cloudsmith, so every build after that comes from your own repo and upstream availability stops affecting your pipeline.

The credential handling and image caching are the operational wins. The broader payoff is that Cloudsmith becomes the control plane across your entire software supply chain. The same policy engine that applies to your application dependencies applies to WizOS images sitting in the same repository. Vulnerability scanning, environmental policies, and access controls run consistently from the base image through to the finished artifact, without separate tooling at each layer.

When your upstreams converge on a single Cloudsmith endpoint (e.g., WizOS, Docker Hub, npm, PyPI), security teams have one governed URL to apply policy to, and development teams have one URL to pull from. Nobody manages a separate credential per upstream, and policy coverage doesn't have gaps between the container layer and the application layer.

WizOS gives you a hardened starting point: images compiled from source, with SLA-backed patching that protects from CVEs. Cloudsmith makes that starting point the default across your org. Developers pull from the same URL with the same credentials. The secure path is also the easiest one.

Want to see how WizOS hardened images and your existing registries can all sit behind one Cloudsmith endpoint? 

Colin Moynes

Senior Support Engineer

Start secure, stay secure with WizOS and Cloudsmith

Shipping software requires two kinds of trust. The first is trust in what you build – that the artifact is secure, compliant, and approved for use. The second is trust in how you deliver it – that the right artifact moves to the right environment, with the right controls, every time.

Pipelines tend to handle the mechanics of both. Where they struggle is maintaining trust across the handoff between the two – and at scale, that gap is where risk compounds. Risk may include untrusted packages slipping through, environment-specific guesswork, manual steps under pressure, or reconstructing audit trails after the fact. Securing the handoff point requires both artifact governance 

 is designed to solve. A golden path makes the secure path the default path – governance baked into the delivery workflow from the start, not added as an afterthought. The Cloudsmith and Octopus Deploy integration is built on that principle.

Continuous trust doesn't emerge automatically from good tooling. Continuous integration (CI) systems build and test. Artifact registries store packages. Deployment tools ship to environments. Each does its job well in isolation. But the connections between these stages – the handoffs – are where governance tends to break down.

Artifacts accumulate in registries without clear signals about which are approved, safe, or compliant. Environment promotion logic gets buried in scripts few people fully understand. Approval processes drift into inboxes and informal agreements. When something goes wrong – or an auditor asks a direct question – there’s a scramble to reconstruct evidence rather than retrieve it.

The problem isn't the tools. It's that no single tool owns the full journey from "is this artifact trustworthy?" to "how, when, and where does it get deployed?" Continuous trust requires answering both questions, and connecting the answers.

Cloudsmith and Octopus Deploy cover that full journey. Each tool owns a distinct half, with a clean policy handoff between them.

Cloudsmith: Artifact trust before deployment

Cloudsmith is a universal artifact registry built for the enterprise. But its role in the delivery lifecycle starts well before an artifact is ready to deploy.

From the moment a dependency enters your environment, Cloudsmith enforces trust. Vulnerability matching, license compliance checks, access controls, and policy management govern what gets in, what gets promoted, and what earns approval for use – consistently, across every team and package format. By the time an artifact reaches Octopus Deploy, the governance work is already done. Trust hasn't just been verified at the gate; it's been maintained throughout.

This answers the question every pipeline needs to resolve: 

Is this artifact safe and approved to deploy?

Octopus Deploy: Controlled delivery from build to production

Octopus Deploy is a dedicated continuous delivery (CD) platform, purpose-built to take over where your CI server ends. It handles the full release orchestration process: environment promotion, approval gates, role-based access control (RBAC), deployment automation, and operational runbooks.

Where CI tools give you a place to run a deployment script, Octopus Deploy gives you a model for how software actually moves through your organization. The same artifact promotes from dev to test to production. Environment-specific variables are scoped without hardcoding. Deployments use strategies like rolling, blue/green, or canary depending on your risk tolerance. A single dashboard shows exactly what version is running in every environment.

This answers the other question your pipeline needs to resolve: 

How, when, and where should this trusted artifact ship?

When Cloudsmith and Octopus Deploy work together, the result is a clear division of responsibility:

Teams configure Octopus Deploy to consume only approved artifacts from Cloudsmith. An artifact is built, stored, and validated in Cloudsmith – with trust enforced at every step. Octopus Deploy picks it up and governs its promotion across environments. The same artifact moves through every stage: no rebuilds, no drift, no manual selection.

End-to-end traceability and audit-ready evidence

Security checks in Cloudsmith and deployment records in Octopus Deploy capture every stage of the journey by design, not after the fact. That means audits stop being fire drills.

Removing manual artifact selection and environment-specific guesswork eliminates a significant source of production incidents. When every team knows what's been approved and exactly how it gets deployed, releases become predictable rather than stressful.

As organizations grow across teams, regions, and infrastructure types – containers, VMs, Kubernetes, hybrid environments – delivery standards tend to fragment. This integration lets platform teams define policies once and reuse them across every infrastructure variation. Legacy workloads and cloud-native services follow the same governed path.

A delivery pipeline is only as trustworthy as its weakest handoff. A golden path fixes that by making governance the default – not a gate teams pass through, but a road built that way from the start.

Cloudsmith and Octopus Deploy together are that road. Cloudsmith maintains artifact trust throughout the lifecycle. Octopus Deploy controls how trusted artifacts move to production. The result is an environment where the secure path and the convenient path are the same, and where audit evidence is a natural byproduct of doing things right.

See what a governed artifact pipeline looks like in your environment. 

Jason Myers

Technical Content Marketer

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

Managing software dependencies is one of those things that sounds simple, but gets really, really tricky. Building enterprise software at scale usually means pulling in thousands of open source libraries, container images, models, OS packages, and other binary artifacts, tracing a dependency graph that can go many levels deep. All this software re-use provides huge benefits in terms of efficiency (why write the same code over and over) and security (use battle-tested code). But it also opens up the software supply chain to threat vectors from malicious actors.

Our partner Chainguard provides an essential service in shipping vulnerability-free container images, along with software packages that are safely built from verified sources. Many of our customers rely on Chainguard for this binary content, processed through the Cloudsmith control plane and served over our distribution network.

Of course, not all of Chainguard’s customers use Cloudsmith. To take advantage of a product like Chainguard Libraries, a typical company will need to address at least a few of these requirements, notably the need to blend Chainguard-sourced Javascript libraries with the global set of packages available from the npmjs public registry. At yesterday’s 

, which provides an npm proxy along with the ability to enforce cooldown and license policies. We expect this functionality will open up a new market for Chainguard Libraries among customers who may not yet have a robust artifact management platform in place.

Naturally, we think the combination of Chainguard + Cloudsmith provides an even better experience. Cloudsmith puts Chainguard content into the broader context of an enterprise’s entire software supply chain, including blending Chainguard indexes with upstream public registries (like npm and PyPI), commercial libraries, and locally sourced packages. Cloudsmith adds critical services like upstream caching; a general-purpose policy-as-code engine; comprehensive scanning for vulnerabilities, licenses, and malware; support for 30+ formats beyond Javascript and Python; a high-performance global package delivery network; logs and observability; and much more.

 as an important addition to their build processes. And we agree wholeheartedly with Chainguard that the most practical way to consume Chainguard Libraries is through an artifact management layer. Given the increased pace of software development with the advent of agentic AI development tools, this degree of security and control is essential for securing the software supply chain.

Glenn Weinstein

Cloudsmith’s take on Chainguard Repository

 will be the first Kubernetes major release of 2026, and it’s full of really exciting updates for security, AI hardware, and more! As always, removing enhancements with the status of “

” we are seeing 80 enhancements in all listed within the 

Kubernetes 1.36 brings a whole bunch of useful enhancements, including 36 changes tracked as ‘

’ in this Kubernetes release. From these, just 

 are currently graduating to stable, such as 

 enhancements graduating to that GA status.

 features are also listed in the enhancements tracker, one of which introduces the ability to report when a PVC was last used in 

. A simple by powerful use-case where users can now see if a PVC is sitting unused, so in larger clusters this would really help DevOps teams to get rid of any unused and unwanted PVCs.

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.36.

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


It’s becoming a regular comment in these recent Kubernetes release notes, but the DRA API is seeing a LOT of exciting enhancements in the 1.36 update. [

 all updated in this release]. This led the Cloudsmith team to add dedicated 

 updates. Anyways, this specific DRA enhancement is exciting because it brings more granularity and automation to hardware management, allowing admins to take specific devices offline for maintenance without disrupting the entire cluster. By introducing taints and tolerations for hardware, similar to what we already have for pod deployments, we can all benefit from automatically rescheduling pods away from failing devices while still letting specialised test pods access them for daily troubleshooting activities.

Nigel Douglas - Head of Developer Relations


I am absolutely thrilled to see OCI image volumes finally hitting Stable status in Kubernetes 1.36 because, as a Product Manager working on the OCI format support at Cloudsmith, I can see this enhancement turning existing container registries into universal artifact hubs. For years, dev teams have been forced into the so-called fat image anti-pattern, where they’re basically bundling massive 

, static assets, and binary plugins directly into their application images, which ultimately creates a nightmare for security patching and bloats deployment times. By graduating this to Stable, we’re now seeing a native, high-performance way to decouple user data from your logic. Devs can now push Hugging Face LLM weights or commercial signatures as independent OCI artifacts and mount them as a 

 just as easily as a ConfigMap. This doesn't just simplify CI/CD pipelines by allowing platform teams to swap content without rebuilding the base engine, but it also drastically shrinks your potential attack surface for the platform teams who are managing these deployments. It’s a massive win for the ecosystem that transforms the OCI registry from a basic storage location for apps into a more dynamic, structured delivery system for any content that a pod needs to succeed.

#5793 Manifest-based Admission Control configuration


As a CSM, I’m genuinely stoked for this 1.36 feature because it finally lets platform teams secure their actual admission control configs. When we think about moving mission-critical policies from the API to static files on the control plane disk, platform teams can now prevent the scary security blindspot where the cluster was vulnerable during the startup. Based on what I'm hearing from the teams I work with, this means vital guardrails (like blocking privileged containers) are now immune to accidental 

 crashes. It’s a massive win for their platform stability, providing platform engineers with a somewhat tamper-proof approach to keeping the 

 secure from the very first second the API server wakes up.

Mutable Container Resources when Job is suspended


This proposal seeks to enhance Kubernetes Batch Job management by relaxing the immutability of a Job’s Pod template while it is in a 

 flag, this change would allow higher-level queue controllers to mutate resource specifications (specifically 

) before a Job is unsuspended and pods are created. By allowing these updates, cluster administrators and automated controllers can dynamically optimise resource allocation based on real-time cluster capacity, current queue priorities, and actual workload utilisation, ensuring that expensive hardware like GPUs is used efficiently.

The design ensures that these mutations are only permitted when a Job is fully suspended and has no active pods, mitigating the risk of disrupting running workloads. While the proposal does not include implementing a specific queue controller or supporting in-place pod updates, it provides the necessary API primitives for external tools (like 

) to perform checkpointing and resizing. This flexibility allows a Job to be suspended, its resource requests lowered to match actual usage, and then resumed, thereby improving overall cluster throughput and reducing resource waste.

Add Recreate Update Strategy to StatefulSet


Starting in Kubernetes 1.36, the introduction of the 

 for StatefulSets addresses a long-standing 

 that has plagued users since 2018. Previously, if a StatefulSet update was triggered with a broken configuration (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become 

 before proceeding. Even if a user reverted the configuration to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing administrators to manually delete the Pod to unblock the controller.

 strategy (moving to Alpha in this update) provides a more aggressive alternative to the standard RollingUpdate. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the 

 deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated CI/CD pipelines and operators can recover from misconfigurations without manual human intervention.

WAS: Integrate Workload APIs with Job controller


The feature represents a major step in Kubernetes' evolution to natively support complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (gang scheduling). This feature introduces the 

 object to act as a link between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.

For the Kubernetes 1.36 Alpha update, the proposal focuses on standardising this integration and refining the API surface. Key changes include introducing the PodGroup as a standalone runtime object and renaming the embedded field within the Workload spec to 

 to ensure a cleaner, more extensible hierarchy. Specifically for the Job controller, the 1.36 update aims to enable the creation of Workload and PodGroup objects by default for 

 Jobs (those where parallelism does not change). This release also seeks to resolve a critical debate on 

, which is whether the release team should maintain separate 

 policies or to unify them into a single parameter where a 

 equal to the total replicas represents strict gang scheduling.

 marked a simple, formal separation of two different KEPs that were previously managed as a single unit: 

 (the Deployment pod replacement policy). The split was justified because the #3973 enhancement which introduced the 

 field to track pods in the process of shutting down moved through the development cycle faster than the more complex pod replacement policy. By decoupling them, the 

 team can now track their graduation through Alpha, Beta, and Stable stages independently, preventing the progress of one from being stalled by the other.

The merged changes include updated documentation and readiness reviews (PRRs for short) for both features. Key technical discussions during the PR focused on ensuring proper version skew policies, specifically requiring that the 

 to avoid status synchronisation issues. While the terminating replicas feature is already seeing implementation in recent releases, the specific API and logic for the pod replacement policy remain in progress, now neatly organised under its own dedicated proposal for future tracking in the 1.36 update.

Graduating to stable, Mutating Admission Policies introduce a declarative, in-process alternative to traditional mutating admission webhooks by leveraging 

. This enhancement allows cluster administrators to define resource modifications (such as injecting sidecar containers, enforcing image pull policies, or setting default labels) directly within Kubernetes using 

 objects. By using CEL's object instantiation alongside 

, the API server can perform these mutations internally, significantly reducing the operational overhead, latency, and webhook fatigue associated with maintaining external infrastructure.

Beyond simplicity, this native approach offers superior performance and reliability. Because the mutations are in-process, the 

 can introspect changes to optimise execution order and safely re-run policies to ensure 

. While it does not aim for 100% feature parity with webhooks, specifically excluding external calls, it covers the vast majority of common use cases while providing a safety field to validate that mutations remain consistent. This move effectively brings the power and efficiency of 

 to the mutation phase, creating a more robust and integrated policy management framework within the Kubernetes ecosystem.

This proposal introduces a mechanism to mitigate 

 in Kubernetes by allowing controllers to detect when their local cache lags behind the API server. Currently, controllers in the 

) rely on eventually consistent watch streams, which can lead to spurious reconciles or incorrect decisions (like scaling or deleting resources) based on outdated data. To solve this, the enhancement proposes an opt-in read-after-write guarantee. By tracking the 

 of objects after a write and updating the 

, controllers can verify if their previous changes have propagated to the local cache before proceeding with the next reconciliation.

In practice, this logic will be integrated into the core processing loops of sensitive controllers, such as the DaemonSet controller. If a controller determines that its cache has not yet caught up to its last-written state, it will 

 the object with exponential backoff rather than performing a potentially erroneous reconcile. This targeted approach ensures consistency for specific resources without imposing a global performance penalty, though it requires careful handling of edge cases like controller restarts and cache resyncs to prevent permanent reconciliation stalls.

Separate kubectl user preferences from cluster configs


 feature introduces a dedicated configuration file (typically located at 

) designed to separate individual user preferences, such as command aliases and default flag settings, from the cluster credentials and server information stored in a standard 

. This separation allows users to maintain consistent local workflows (like enforcing interactive delete confirmations or silencing deprecation warnings) across multiple clusters without modifying shared or auto-generated connection files. The major change moving into 

, whereas it previously required manual activation. To support this promotion, the update introduces the 

 management command to help users programmatically view and edit their preferences, and it formalises security controls through a 

 to prevent the execution of untrusted binaries.

This relaxed ServiceName validation feature is an improvement designed to bring the naming constraints of Service resources into alignment with other standard Kubernetes objects. Historically, Services were restricted by a stricter 

), which prohibited names from starting with a numeric digit. This update transitions the validation to the more flexible 

 standard, finally allowing users to create Services with names like 

, the feature is moving from an opt-in experimental state to being 

. This graduation signifies that the community has successfully completed compatibility testing with downstream systems like DNS providers and Ingress controllers, and has verified that the change remains safe during cluster upgrades and downgrades by maintaining immutability checks on existing resource names.

Extend PodResources to include resources from DRA


 to help improve visibility gap between the Kubernetes node and external monitoring tools. Historically, this API only allowed monitoring agents to see which CPUs or standard devices were assigned to a container. This feature extends that capability to include resources managed by the evolving DRA feature. By adding a 

 method for targeted pod queries, the Kubelet can now report specific DRA-allocated hardware (such as GPUs or FPGAs) directly to monitoring stacks like 

. To ensure this data remains available even if a DRA driver goes offline, the system implements a checkpointing mechanism within the 

, guaranteeing that resource assignments are preserved across Kubelet restarts.

The primary benefit of this enhancement is 

granular observability for next-gen hardware

. Platform operators can now access per-pod metrics for DRA-managed resources, which is essential for accurate billing, performance tuning, and troubleshooting in AI/ML workloads. Since the feature is graduating to Stable in v1.36, the community can expect full production-ready reliability with a guaranteed 

 requests over a rolling 5-minute window as well as low-latency response times (P99 < 100ms). The graduation to GA means the 

, allowing third-party ecosystem tools to officially rely on stable gRPC fields without the risk of breaking changes or experimental instability.

This is a security-focused refinement of how Kubernetes handles network addressing, specifically targeting the stricter validation of 

 across the API. Historically, Kubernetes relied on older Go functions that were overly permissive, allowing ambiguous formats like IPv4 addresses with leading zeros (for example: 

), which different systems might interpret differently (octal vs. decimal), potentially leading to security vulnerabilities like 

. For platform teams, this is highly beneficial because it eliminates many IP address risks and ensures consistency between Kubernetes and underlying network plugins (Calico and Cilium) and OS-level libraries. To maintain stability, the plan uses 

, which prevents new invalid entries without breaking existing workloads, which means that teams can update a service’s labels without being forced to immediately fix a legacy IP field. This move toward canonical formats (like standardised IPv6 strings) simplifies long-term maintenance, auditing, and observability, as platform engineers can now trust that network data is unambiguous and follows a single source of truth format across the entire cluster.

API for external signing of Service Account tokens


This KEP proposes a transition from static, file-based Service Account key management to a more dynamic integration with external providers like 

 loads signing keys from the local disk at startup, a method that lacks flexibility and poses a security risk, as any user with filesystem access could exfiltrate the signing material. By introducing a new 

) accessible via a Unix domain socket, Kubernetes can delegate JWT signing and public key retrieval to an external plugin. This shift enables seamless key rotation without requiring an API server restart and ensures that sensitive private keys never reside in the cluster’s local memory or storage.

To maintain consistency and security, the 

 remains responsible for assembling the JWT claims and headers, while the external signer only provides the signature. This architecture prevents claim divergence and ensures that externally signed tokens remain compatible with existing OIDC discovery endpoints. While the proposal introduces a new 

 flag, it preserves backward compatibility by keeping existing file-based flags as mutually exclusive options. Potential performance overhead from socket communication will be mitigated through benchmarking, and access to the signing socket will be restricted via standard Unix file permissions to prevent unauthorised token generation.

Kubernetes 1.36 introduces a brand-new conditional authorisation capability, which is a framework that allows authorisation decisions to depend on the actual data within a resource (like specific fields or labels) rather than just its metadata. Currently, Kubernetes authorisers (like 

) are basically blind to the content of a request body. This KEP has a two-phase evaluation process. 

In the first phase, the authoriser performs 

 response containing a set of requirements (for example, " only Allow if 

In the second phase, these conditions are enforced during the 

 stage, where the API server finally decodes the object and has access to the necessary field data to make a concrete decision.

This architecture solves several long-standing limitations by providing a unified, cohesive policy model that spans both authorisation and admission. It eliminates the need for administrators to essentially over-grant their permissions in RBAC only to restrict them later with separate tools like 

By propagating conditions through the request chain, the system ensures atomicity (the decision is based on a single snapshot of policy) and improves user experience, as users can see exactly why they are restricted via 

 lookups. Concretely, the enhancement extends the 

 API, enabling both in-tree and out-of-tree authorisers to implement fine-grained controls, like restricting which fields user can update or which 

 a CSR can use without compromising API server's performance or security.

Constrained impersonation helps Kubernetes move away from the unrestricted legacy model where an impersonator automatically inherits all permissions of the target user. To mitigate these security risks (especially for controllers and per-node agents) impersonators must now possess two distinct sets of permissions: 

The authority to impersonate a specific identity (

Right to perform specific actions on behalf of that identity (

This opt-in mechanism ensures that even if a controller is compromised, its impersonation power is limited to specific resources and verbs. In the below 

 example, a controller can be restricted to impersonating only the specific node it is running on by using the downward API to identify itself and configuring the client as follows:

By introducing these prefixed verbs like 

, platform engineers can now define highly specific RBAC roles. This setup ensures that an impersonator can only execute a request if both the impersonator has the 

 permission for the action and the impersonated principal has the underlying permission to perform the task itself.

Kubernetes 1.36 is addressing a long-standing recovery gap where encrypted API resources become undeletable due to missing keys or data corruption. Currently, if a single object in 

 fails to decrypt or decode, listing that resource type fails entirely, forcing admins to bypass the Kubernetes API and manually manipulate the database, which is a really risky and complex process. To solve this, the proposal introduces a way to identify these broken resources and provides a new 

 that allows for their removal even when their content remains unreadable.

However, this unconditional delete is a high-risk operation. Since the system cannot read the object's metadata, deleting it bypasses standard safety features like finalisers and 

, potentially leaving orphaned system processes (like running Pods) behind. To mitigate this, the design includes a new 

 for better diagnostics and requires explicit confirmation through 

 prompts and server-side admission layers to ensure administrators understand the impact before purging malformed data.

This enhancement introduces support for user namespaces, a critical isolation feature that maps containerised user and group IDs to different, unprivileged IDs on the host. By allowing a process to hold root privileges within a pod while remaining unprivileged on the underlying node, the KEP significantly bolsters node-to-pod and pod-to-pod isolation. This ensures that even if a process achieves a container breakout or possesses elevated capabilities like 

, its impact is strictly confined to the namespace, preventing it from exercising administrative control over the host or other pods.

The implementation specifically addresses and mitigates several high-severity vulnerabilities where container escapes or privilege escalations previously threatened host integrity. Key CVEs resolved or dampened by this update include:

Using AWS CodeBuild to push packages to Cloudsmith

More articles

Start secure, stay secure with WizOS and Cloudsmith

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

Cloudsmith’s take on Chainguard Repository

Kubernetes 1.36 – What you need to know

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith

Secure containers by default with Cloudsmith and Docker Hardened Images