AzureFeeds

Container security within Microsoft Defender for Cloud has helped security teams protect their Kubernetes workloads with deep visibility, real-time threat detection, and cloud-native runtime protection. Up until now it’s been delivered via Azure Kubernetes Service (AKS) add-on or Arc for Kubernetes extension, providing a streamlined, fully managed experience, deeply integrated with Azure. But for some teams, especially those operating in complex, multi-cloud environments or with specific operational requirements, this could introduce constraints around customization and deployment. 

To address this, we’ve introduced Helm support, making it easier to deploy the sensor for container security and enabling greater agility, customization, and seamless integration with modern DevOps workflows. 

Customers can now choose whether to use Helm to deploy the sensor or to use the previous method to deploy it as an AKS add-on or an Arc for Kubernetes extension for clusters outside of Azure. 

But why does this matter? Let’s take a step back. 

The backstory: Why we need more flexibility 

Since we first introduced our sensor back in 2021, deploying it meant using the built-in AKS add-on or provisioning it through Arc for other environments. This is one of our enablers for the “auto-provisioning” feature, which automatically installs and updates our sensor on managed clusters. This approach made setup simple and tightly integrated but also introduced some friction. 

• Wait for the AKS release cycle to roll out new features. 

• Harder to achieve custom deployment models, like GitOps or advanced CI/CD integrations. 

• Limited support existed for configuring the sensor in non-standard environments. 

This was fine for many teams, but in larger organizations with multiple teams, strict change management, and complex multi-cluster environments, the lack of deployment flexibility of the sensor could slow down operations or create friction with established workflows. 

Deploying via Helm: Why is it a big deal? 

Helm is the de facto package manager for Kubernetes, trusted by DevOps teams to install, configure, and manage workloads in a consistent, declarative way. 

We’re now supporting Helm as a standalone deployment option – giving you direct access to the helm chart without the abstraction provided by the AKS add-on or Arc for Kubernetes extension. 

This means you can now deploy and manage the sensor like any other Helm-managed workload with full control over when, how, and where it’s deployed, all while aligning naturally with GitOps, CI/CD pipelines, and your existing infrastructure-as-code practices. 

Helm supports multi–cloud with less overhead 

Traditionally, deploying Defender for Cloud on non-AKS clusters like EKS and GKE required onboarding those clusters to Azure Arc for Kubernetes. Arc provides a powerful way to centrally manage and govern clusters that live outside Azure, which is ideal for organizations looking to apply Azure-native policies, inventory, or insights across hybrid environments. 

But what if all you want is Defender for Cloud’s runtime security with minimal operational overhead? 

That’s where Helm comes in. 

With Helm, you can now deploy the sensor without requiring Arc onboarding, which means: 

• Smaller footprint on your clusters 

• No access required for your Kubernetes API server  

• Simpler setup focused purely on security 

This approach is ideal for teams that want to integrate Defender for Cloud into existing EKS or GKE environments while staying aligned with GitOps or CI/CD practices — and without pulling in broader Azure governance tooling. 

Arc still plays an important role in hybrid Kubernetes management. But if your goal is to quickly secure workloads across clusters with minimal configuration, Helm gives you a lightweight, purpose-built path forward. 

What you can do with Helm-based deployment 

1. Opt-in to adopt new Private, Public Preview or General Availability (GA) features as soon as they’re published. Great for early adopters and fast-moving teams.


2. Gain more control over upgrades by integrating into CI/CD and GitOps. Whether you’re using ArgoCD, Flux, or GitHub Actions, Helm makes it easy to embed Defender for Cloud into your pipelines. This means consistent deployments across clusters and security that scales with your application delivery.


3. Override values using your own YAML files, so you can fine-tune how the sensor behaves based on RBAC rules, logging preferences, or network settings.


4. Experiment safely by deploying Defender for Cloud in a dev cluster. Validate new features, tear it down, and repeat the cycle. Helm simplifies experimentation, making it easier to test without risking your production environment. 

The (not so) fine print 

While Helm unlocks flexibility, there are still a few things to keep in mind: 

• Helm support is for the sensor component only, not the full Microsoft Defender for Cloud configuration experience. 

• If you are moving to Helm, the “auto-provisioning” feature doesn’t work. Meaning you are responsible for version upgrades and version compatibility, especially when integrating with CI/CD tools that manage Helm releases automatically. 

Ready to deploy? 

You can learn more on how to deploy the sensor via Helm to protect your containerized environment with Defender for Cloud