We value your privacy

We use cookies to analyze site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Defender for Containers
Microsoft Defender for Containers for US businesses

Nothing that happened before you switched this on produces an alert. Whatever is already running is simply invisible to it.

Alerts fire only for actions and deployments that happen after the plan is enabled on your subscription. Switching it on does not audit the cluster you already have. It begins watching from that instant, which is an excellent reason to enable it this afternoon rather than during whatever happens next quarter.

Book a container security reviewSee what it covers
Microsoft Defender for Containers for US organizations
  • 60+Kubernetes-aware analytics and anomaly detections
  • 5 domainsPosture, vulnerability, runtime, supply chain, deployment
  • AgentlessDiscovery and vulnerability assessment
  • DailyVulnerability re-scans, with zero configuration
What Defender for Containers covers

Eight capabilities, and which side of the agentless line each falls on genuinely matters.

Part of this works the moment the plan is enabled, with nothing whatsoever installed in your clusters. Part of it needs the sensor deployed. Knowing which half is which is what tells you what you genuinely have once the switch is flipped.

Agentless discovery with zero footprint

Discovery of your clusters, their configuration and what is deployed in them, done entirely through the API with nothing installed anywhere. In a company where adding any component to a production cluster means a change request and a committee, this is the part that delivers value before that conversation even starts.

Vulnerability assessment across registries and running containers

Images in your registries, containers actually running, and supported nodes all assessed without an agent, rescanned daily, requiring no configuration at all, covering both operating system and language packages, and telling you which findings are genuinely exploitable. Registry coverage spans Azure, the AWS registry and both Google ones.

Findings signed for integrity

The findings themselves are signed with a Microsoft certificate so their integrity and origin can be proven, and attached to the image in the registry for anybody who needs to validate them. That signature stops being a curiosity the moment those findings feed a deployment gate rather than a report somebody skims.

Gated deployment against your own policy

Deployment rules can either record or outright refuse a deployment where the image fails your vulnerability policy. This is the step that converts scanning from information into an actual control, and it is also the step nearly everybody postpones, because it is capable of stopping a release on a Friday afternoon.

Runtime detection at cluster, node and workload level

More than sixty detections that understand Kubernetes, built on analytics, machine learning and anomaly detection against what your workloads actually do. Some of it needs the sensor installed, the rest works from the audit logs alone. Every alert maps onto the recognized attack technique matrix for containers.

Binary drift detection, and blocking

With the sensor in place, a process appearing inside a container that has no business being there raises an alert, and separately can be stopped outright. You write the drift policy yourself, and that policy is what separates a legitimate operational action from something that should never be executing in there.

Data plane hardening through admission control

Install the Kubernetes policy component and every request reaching the API server is checked against a set of established practices before it is ever written to the cluster. The worked example given is refusing to create privileged containers, with subsequent requests simply blocked.

Knowing which clusters are actually protected

There is a view showing which clusters have no sensor or are otherwise incompletely protected. Where engineering teams create clusters without asking anybody, that single view is what stops container security becoming something you did once, for the clusters you happened to know about that month.

The sentence that decides when to enable

Alerts cover only what happens after the moment you enable it.

This is stated outright, and the practical consequence follows directly: switching the plan on is not a way to discover what already happened.

  • Runtime detection begins at the moment of enablement and not a second earlier. A cluster compromised last month generates no retrospective alerts at all, and nothing in the portal makes that absence of history obvious to somebody looking at an empty list. Which is precisely the argument for enabling it long before anybody suspects a problem.
  • The posture and vulnerability side behaves differently. Agentless discovery and assessment examine what exists right now, so images and configurations that predate enablement are assessed perfectly well. It is only the runtime alerting that starts from zero.
  • That distinction matters enormously when planning how you would respond to something. If a container question arises and the plan went on last Tuesday, your vulnerability and configuration picture is complete, while your runtime alert history stretches back exactly as far as last Tuesday.
  • The related point is the sensor. Some capabilities are agentless and work from the first minute, whereas antimalware, DNS detection, and detecting or blocking unexpected binaries all need the sensor present. A cluster without one has posture coverage and no runtime coverage, and that is remarkably easy to misread as being fully protected.
Ask us to check sensor coverage
How we approach it

Four things that decide whether container security actually sticks in a real company.

What makes container security unusual is that the security team almost never owns the clusters. Nearly every practical difficulty flows from that one fact, and getting the sequence right is what resolves it.

We start with what needs no permission

Discovery runs through the API and leaves no footprint at all, and the vulnerability assessment needs no configuring. So you arrive at the conversation about installing something in a production cluster already holding an inventory, configuration findings and vulnerability data. That changes the tone of the conversation considerably.

We are explicit about what the sensor adds

Antimalware, DNS detection, and both detecting and blocking unexpected binaries all require the sensor. A cluster with posture coverage and no sensor is partly protected in a way the summary views do not make remotely obvious, and saying so out loud prevents a comfortable but false sense of completeness.

We introduce gating in audit mode first

Deployment rules will either record or refuse an image that fails your policy. Start by refusing and you have created the thing engineering teams spend a quarter finding ways around. Start by recording and you generate the data that makes the policy something you can negotiate and then genuinely agree.

We enable early because alerting is not retrospective

Alerts only ever cover actions and deployments happening after enablement. There is no configuration, no setting and no support case in which switching it on mid-incident tells you what happened last month. Having it on before you need it is the whole of the value.

How a deployment runs

Four phases across roughly six to eight weeks.

The agentless half can be running inside a week. Deploying the sensor and deciding on gated deployments are what consume the calendar, because both of those touch clusters belonging to engineering teams rather than to you.
  1. 01
    Week 1

    Enable and see what agentless discovery finds

    The plan switched on and agentless discovery running, neither of which installs a thing. That alone produces an inventory of clusters, findings against their configuration, and a vulnerability assessment covering both registry images and running containers. It also, with some regularity, turns up clusters the security team had no idea existed.

    • Plan enabled at subscription scope
    • Cluster inventory from agentless discovery
    • Registry and running container vulnerability findings
    • Control plane hardening recommendations reviewed
  2. 02
    Weeks 2 to 4

    Deploy the sensor where runtime protection matters

    Deploying the sensor is negotiated with whoever owns each cluster, and prioritized by what the workload does rather than by how many clusters somebody has. Antimalware, DNS detection and the drift capabilities all rest on it, so this is where runtime coverage genuinely originates.

    • Sensor deployed to prioritized clusters
    • Clusters missing sensors identified and tracked
    • Runtime alerts flowing and routed
    • Defender XDR investigation path confirmed
  3. 03
    Weeks 5 to 6

    Harden the data plane through admission control

    The Kubernetes policy component installed so that every request to the API server is checked before it is written anywhere. It starts in audit mode so teams can see exactly what would have been refused, then moves to enforcement on the rules everybody has actually agreed with, privileged containers being the obvious first one.

    • Azure Policy for Kubernetes installed
    • Policies run in audit and reviewed with owners
    • Enforcement enabled on agreed rules
    • Exception process defined for legitimate cases
  4. 04
    Weeks 7 to 8

    Gate deployments and set drift policy

    Deployment rules configured to record first and only later refuse images failing the vulnerability policy, and drift policies written carefully enough that the alerting separates legitimate operational activity from a genuine problem rather than producing noise nobody reads.

    • Vulnerability policy agreed with engineering
    • Gated deployment in audit, then enforcing
    • Binary drift policies defined per workload type
    • Blocking enabled where drift policy is confident
Where this matters

Six situations where container security needs attention.

What links these is a container estate that grew out of a decision an engineering team made rather than an infrastructure program somebody funded, which describes almost all of them.

A business whose developers built the Kubernetes estate

Clusters spun up by engineering teams to solve a delivery problem, with security brought in late or never. Agentless discovery produces exactly the inventory that conversation needs, and it regularly surfaces clusters nobody outside a single team had ever heard of.

A regulated firm asked about container vulnerability management

SOC 2 auditors, insurers and the security questionnaires large customers send all now ask two things: are images scanned, and can a vulnerable one still be deployed. Daily rescanning with exploitability data answers the first. Deployment rules that refuse images failing your policy answer the second, concretely, with evidence.

An organization running privileged containers by default

Extremely common, and almost never a deliberate decision anybody took. The Kubernetes policy component checks every request to the API server against established practice before it is written, and the worked example is exactly this: refuse to create privileged containers, and block every subsequent request.

An operator with clusters across cloud and on-premises

Coverage extends to containerized assets across several clouds and across your own hardware, with vulnerability assessment reaching registries on Azure, AWS and Google alike. For an estate that became multicloud through acquisitions rather than through anybody design, having one consistent view is the principal benefit.

A company that had a cryptomining incident

Binary drift detection alerts on unauthorized external processes within containers and drift blocking prevents them, both sensor-based. That is the direct control for the classic container compromise, where a legitimate workload starts running a process nobody deployed.

A business whose exposure came from a service definition

Documented detections include exposed Kubernetes dashboards and exposed services where a LoadBalancer type is created or updated and publicly exposes workloads. Those are configuration mistakes that produce internet exposure, and they are the detections most likely to matter first.

Three positions

How US organizations secure containers.

The middle column is where most companies are, and it is a perfectly reasonable place to stop for a while: posture visibility without going anywhere near a production cluster. The gap is that runtime protection happens to be the half requiring the sensor.
Cluster inventory
Agentless plus sensor plus gatingComplete
Agentless onlyComplete
Registry scanning in the pipelineNone
Image vulnerability findings
Agentless plus sensor plus gatingYes, daily
Agentless onlyYes, daily
Registry scanning in the pipelineAt build time only
Running container assessment
Agentless plus sensor plus gatingYes
Agentless onlyYes
Registry scanning in the pipelineNo
Runtime threat detection
Agentless plus sensor plus gatingFull
Agentless onlyAudit log based only
Registry scanning in the pipelineNone
Antimalware inside containers
Agentless plus sensor plus gatingYes
Agentless onlyNo
Registry scanning in the pipelineNo
Binary drift blocked
Agentless plus sensor plus gatingYes
Agentless onlyNo
Registry scanning in the pipelineNo
Admission control hardening
Agentless plus sensor plus gatingYes
Agentless onlyNo
Registry scanning in the pipelineNo
Vulnerable images blocked at deploy
Agentless plus sensor plus gatingYes
Agentless onlyNo
Registry scanning in the pipelineSometimes
Cluster changes require engagement
Agentless plus sensor plus gatingYes
Agentless onlyNo
Registry scanning in the pipelineNo
Time to first value
Agentless plus sensor plus gatingDays for posture
Agentless onlyDays
Registry scanning in the pipelineAlready in place
Feature
Agentless plus sensor plus gating
Agentless only
Registry scanning in the pipeline
Cluster inventory
CompleteCompleteNone
Image vulnerability findings
Yes, dailyYes, dailyAt build time only
Running container assessment
YesYesNo
Runtime threat detection
FullAudit log based onlyNone
Antimalware inside containers
YesNoNo
Binary drift blocked
YesNoNo
Admission control hardening
YesNoNo
Vulnerable images blocked at deploy
YesNoSometimes
Cluster changes require engagement
YesNoNo
Time to first value
Days for postureDaysAlready in place
Agentless against sensor based

What arrives without touching a cluster, and what genuinely needs the sensor.

Understanding this split before enabling anything is the most useful preparation there is, because it determines exactly how much a change-averse company can adopt on day one.

Capability

Kubernetes cluster and configuration discovery

Requires the Defender sensor
No, API based with zero footprint

Capability

Registry image vulnerability assessment

Requires the Defender sensor
No, agentless

Capability

Running container vulnerability assessment

Requires the Defender sensor
No, agentless

Capability

Kubernetes node vulnerability assessment

Requires the Defender sensor
No, agentless for supported nodes

Capability

Control plane hardening recommendations

Requires the Defender sensor
No

Capability

Detection from Kubernetes audit logs

Requires the Defender sensor
No, agentless coverage

Capability

Antimalware within containers

Requires the Defender sensor
Yes

Capability

DNS detection from container workloads

Requires the Defender sensor
Yes

Capability

Binary drift detection and blocking

Requires the Defender sensor
Yes

Capability

Data plane hardening by admission control

Requires the Defender sensor
Needs Azure Policy for Kubernetes
CapabilityRequires the Defender sensor
Kubernetes cluster and configuration discoveryNo, API based with zero footprint
Registry image vulnerability assessmentNo, agentless
Running container vulnerability assessmentNo, agentless
Kubernetes node vulnerability assessmentNo, agentless for supported nodes
Control plane hardening recommendationsNo
Detection from Kubernetes audit logsNo, agentless coverage
Antimalware within containersYes
DNS detection from container workloadsYes
Binary drift detection and blockingYes
Data plane hardening by admission controlNeeds Azure Policy for Kubernetes
How an engagement runs

Five steps, sequenced around who owns the clusters.

The technical order and the organizational order are the same here: take what needs no permission first, and use its findings to justify what does.
  1. 1

    Enable and run agentless discovery

    Discovery of clusters, their configuration and what is deployed, all through the API and leaving nothing behind, plus vulnerability assessment of registry images, running containers and supported nodes, rescanned every day. Nothing is installed anywhere, which is why this can happen this week rather than next quarter.

  2. 2

    Review posture findings with the cluster owners

    The hardening recommendations and vulnerability findings go to whoever owns each cluster, ordered by what is genuinely exploitable rather than by count. This conversation is also the one that tells you whether deploying the sensor is going to be a formality or a fight.

  3. 3

    Deploy the sensor where runtime coverage matters

    Ordered by what each workload actually does rather than rolled out uniformly, because antimalware, DNS detection and the drift capabilities all rest on the sensor. Clusters without one are tracked explicitly, so partial coverage stays visible instead of quietly being assumed away.

  4. 4

    Add admission control, in audit before enforcement

    The Kubernetes policy component installed so that every request reaching the API server is checked before it is written. It runs in audit first, so teams can see precisely what would have been refused, then enforcement follows on the rules people have genuinely agreed to, beginning with privileged containers.

  5. 5

    Gate deployments and tune drift policy

    Deployment rules that record first and only later refuse an image failing the vulnerability policy, plus drift policies written so that alerts separate normal operational activity from a real problem. Neither survives contact with a release deadline unless engineering has actually agreed to it.

Straight answers

What US organizations ask about Defender for Containers.

Not for all of it. Discovery runs through the API leaving no footprint, and vulnerability assessment of registry images, running containers and supported nodes is agentless and needs no configuration. Antimalware, DNS detection, and detecting or blocking unexpected binaries all genuinely do require the sensor.

On posture and vulnerabilities, yes, because both examine what exists at this moment. On runtime threats, no. Alerts are triggered only for actions and deployments occurring after the plan is enabled on your subscription.

The Azure registry, the AWS one, both Google registries, and supported external registries besides. It also scans running containers daily without caring which registry they came from, though that last part is still in preview across multiple clouds.

Every day, with nothing to configure, covering both operating system and language packages, and telling you which findings can genuinely be exploited. What it finds goes into the cloud security graph, where it feeds contextual risk scoring, attack path calculation and hunting.

Yes, through the deployment gate. Rules can either record or refuse a deployment where the image fails your vulnerability policy. Starting in audit is the sensible order, because blocking releases before anybody has agreed the policy does lasting damage to your relationship with the engineering teams.

A capability requiring the sensor, which raises an alert when a process appears inside a container that has no business being there, and a companion capability that stops it outright. You define the conditions in a drift policy, and that policy is what separates ordinary operational work from something genuinely wrong.

The Kubernetes policy component handles it. Once policies exist, every request arriving at the API server is checked against established practice before anything is written to the cluster. The worked example given is exactly the obvious one: refuse to create privileged containers, and block every request afterward.

More than sixty detections that understand Kubernetes, built on analytics, machine learning and anomaly detection against what your workloads actually do. Every alert maps onto the container attack technique matrix, developed by the Center for Threat-Informed Defense working closely with Microsoft, which makes categorizing and explaining them considerably easier.

Defender for Cloud feeds into Defender XDR, so analysts investigate and respond to container problems in the same place they handle everything else. That keeps a container investigation from becoming a separate console nobody opens.

The exposure findings usually matter most immediately: a dashboard reachable from outside, and a load balancer service created or changed in a way that publishes a workload to the internet. Creating a highly privileged role and creating a sensitive mount are the other two documented examples.

Yes. Containerized assets are covered across several clouds and on your own hardware, with vulnerability assessment reaching registries on Azure, AWS and Google. What coverage you get does vary by cloud and by feature, and there is a published support matrix worth reading against your particular mix before assuming anything.

There is a whole area dedicated to exactly this, watching for clusters with no sensor and giving you somewhere to manage the ones nobody is monitoring. Where engineering teams create clusters without asking, that view is the entire difference between having coverage and appearing to have coverage.

It answers the container questions those processes ask: whether images are scanned for vulnerabilities, how often, whether vulnerable images can reach production, and whether runtime threats in the cluster would be detected. Daily agentless scanning, gated deployment and the 60+ runtime detections give you evidence-backed answers rather than assurances. Your auditor owns the interpretation; the configuration and the evidence are what we deliver.

Yes, and it is precisely the order we recommend. Discovery runs through the API with no footprint and the vulnerability assessment needs no configuring, so the inventory, the configuration findings and the vulnerability data all land before anybody has to ask a team about installing something in a running cluster.

Those images are maintained by Microsoft and published to their own registry, so nobody on your side modifies or patches them. Updates arrive either through the managed Kubernetes release lifecycle where the add-on is used, or within thirty days as new chart versions where Helm is. Find a vulnerability in one and the route is an Azure support request naming the image, the tag and the CVE.

Each engagement is scoped and quoted individually, sized by how many clusters exist and how many separate teams own them, since it is the organizational side that governs the pace rather than the technology. The step that costs nothing: enable the plan and let agentless discovery run for a week. The cluster inventory it hands back is usually eye-opening on its own.
Coverage check

Fifteen questions about your own container estate.

Most of the first block can only be answered once agentless discovery has run, which is itself an argument for enabling it early.

Estate

  • How many Kubernetes clusters do we run?
    Including ones teams created.
  • Which are missing the Defender sensor?
    Deployment monitoring shows this.
  • Which registries do we pull from?
    ACR, ECR, GAR, GCR and external.
  • Do we run clusters outside Azure?
    Multicloud and on-premises are in scope.
  • When was the plan enabled?
    Alerts start from then.

Vulnerability

  • Are registry images being scanned?
    Daily re-scans, zero configuration.
  • Are running containers scanned too?
    Separate from registry scanning.
  • Do we have a vulnerability policy?
    Gating needs one.
  • Do we act on exploitability insights?
    They prioritize the list.
  • Are node vulnerabilities in scope?
    Supported nodes are covered.

Control

  • Is Azure Policy for Kubernetes installed?
    Needed for data plane hardening.
  • Do we block privileged containers?
    The documented example.
  • Is gated deployment auditing or blocking?
    Start with audit.
  • Have we defined drift policies?
    They shape alert quality.
  • Who investigates container alerts?
    Defender XDR is the surface.
Related reading

The pages around this one.

Microsoft Defender for Cloud

The parent product and the other workload protection plans.

Learn more

Defender for Servers

The equivalent protection for virtual machine workloads.

Learn more

Microsoft Defender

The wider Defender family this plan's alerts investigate through.

Learn more
Next step

Switch the plan on and let agentless discovery run for seven days.

Nothing gets installed, and what comes back is a cluster inventory, findings against their configuration, and vulnerability data. It also starts the runtime alerting, which covers only what happens from that point forward.

Book a container security reviewSee Microsoft security services

Related Services

Explore more solutions that work great with this service

Microsoft Defender for Cloud Services

Defender for Cloud deployment for US organizations: enabling free

Learn more

Microsoft Defender for Servers

Defender for Servers engagements for US organizations: estate

Learn more

Microsoft Defender for Storage

Defender for Storage deployment for US organizations: storage

Learn more

Microsoft Defender Vulnerability Management Services

Defender Vulnerability Management deployment for US organizations:

Learn more

Microsoft Defender XDR Services

One incident queue across endpoint, email and identity

Learn more

Microsoft Security Services

The Microsoft security stack deployed and managed end to end

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support USA
  • IT AMC USA
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA