Container Security
Microsoft Defender for Containers
Microsoft Defender for Containers is a cloud-native offering inside Microsoft Defender for Cloud that provides posture management, vulnerability assessment, and runtime threat protection for Kubernetes clusters and container registries. It is delivered as a managed plan billed per protected resource, applies agentless and sensor-based controls across multi-cloud clusters (AKS, Arc, EKS, GKE), and centralizes findings, recommendations, and alerts in Defender for Cloud.
Azure
Service information
Shortname: Defender Containers
Huawei equivalent shortnames: CGS
Keywords: container security, vulnerability, runtime protection
Differences vs Huawei
Defender for Containers spans posture, registry image scanning, and runtime threat detection in one plan, with a Microsoft Defender for Cloud console, Azure Policy integration, and connector model for AWS/GCP. Huawei CGS is narrower: it scans images in SWR and running images on CCE nodes, builds process/file whitelists and escape rules, and reports in the CGS console. Posture benchmarks, regulatory mapping, and multi-cloud Kubernetes governance are not part of CGS; replicate them through HSS, CCE admission controls, or external tooling, and verify coverage per control before calling them equivalent.
Architecturally, Defender runs a managed sensor (Azure Arc + Defender sensor) on each cluster node plus registry-side scanning, and surfaces alerts through Microsoft Sentinel and Defender for Cloud APIs. CGS deploys a lightweight CGS Container agent per node managed by a Management Master, with a Huawei-owned vulnerability intelligence base. There is no published CGS-equivalent of Defender's control-plane audit log analytics, Kubernetes API threat detection, or Sentinel correlation pipeline; expect to wire CGS events into CSS/LTS and Security Center manually rather than inheriting a unified SIEM-security binding.
Operationally, Defender for Containers bills as a protected-resource tier per node-hour and per registry image, while CGS bills by protected nodes and scan volume through CGS pricing. Defender's policy model is declarative Azure Policy gated at admission and continuously reassessed; CGS policy is whitelist- and rule-based behavior enforcement on the running node. Cross-region, Arc-enabled, and disconnected cluster support differs materially—validate that CGS meets your region and CCE version requirements, since CGS is CCE/SWR-scoped and not a drop-in for non-Huawei or self-managed clusters.
Migration to Huawei
Assess Defender for Cloud inventory first: list plans, protected subscriptions, AKS/Arc/EKS/GKE clusters, registry scans, and active recommendations. Map each control to a Huawei target—CGS for image vulnerability scanning, runtime escape and whitelist behavior, and escape detection; HSS for node host intrusion detection; CCE security policies/neutron groups for network and admission controls; SWR for registry storage with CGS scanning. Confirm CGS region availability and supported CCE/Kubernetes versions per cluster, since CGS is bound to CCE-managed nodes and SWR registries rather than arbitrary self-managed Kubernetes.
Replatform registry and runtime protection by migrating images from ACR to SWR using scripted docker pull/push or a sync job, then enabling CGS SWR image scanning and running-image scanning on the rebuilt CCE clusters. Re-express Defender recommendations and Kubernetes audit policies as CCE admission controls, network policies, and CGS process/file whitelists; baseline whitelists from observed steady-state behavior in staging before enforcing block mode to avoid breaking workloads. No automated Azure-to-Huawei migration tool exists for Defender plans or alert history, so rebuild policy and baseline state manually.
Validate security parity pre-cutover by running CGS and the equivalent Huawei controls in monitor mode alongside Defender for Cloud, comparing vulnerability findings, escape detections, and posture recommendations for the same workloads. Forward CGS alarms to LTS/CSS or an existing SIEM and validate alert routing, severity mapping, and on-call response playbooks; reconcile gaps such as Kubernetes API audit analytics and CIS/ regulatory benchmark posture that CGS does not natively deliver. Cap cutover only after a defined detection parity bar is met for your most critical clusters.
Expect material cost-model and scope differences. Defender bills per protected node-hour plus per-image registry scans across multi-cloud; CGS plus HSS plus WAF/CFW billing is per node, scan volume, and edition, with no Defender-style plan tier. Recalculate TCO using peak node count, scan frequency, retention, and interconnect traffic for cross-cloud clusters, and budget for the manual SIEM and posture tooling needed to cover gaps Defender filled natively. Treat CGS as the core image/runtime equivalent, not a full Defender for Containers replacement, and document residual gaps in architecture decision records.
Huawei Cloud
Huawei equivalent service
Shortname: CGS
General function: Container Security
Container image and runtime security service.
Keywords: container security, vulnerability, runtime protection