Skip to main content
emnode
Compliance High severity MCSB PV-4

Microsoft Defender for Cloud · Containers

Vulnerabilities in container security configurations should be remediated

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Vulnerabilities in container security configurations should be remediated" check?

Flags unmanaged Docker hosts, IaaS Linux VMs or other Linux machines with Docker installed, whose configuration drifts from the CIS Docker Benchmark. Defender for Servers Plan 2 runs the full CIS ruleset against the daemon, the host and the runtime, then groups every failed control into this single recommendation. It assesses self-managed Docker only: AKS-managed nodes and Databricks-managed VMs are out of scope and surface as 'Not applicable', and machines with no Docker installed report compliant. Note the underlying policy 'Vulnerabilities in container security configurations should be remediated' (e8cbc669-f12d-49eb-93e7-9273119e9933) was deprecated in October 2024 alongside the Azure Monitoring Agent, so treat its findings as advisory and plan a migration path.

Why does "Vulnerabilities in container security configurations should be remediated" matter?

A misconfigured container host is close to a full compromise: a permissive Docker daemon socket, a container run with --privileged, or world-readable TLS material lets an attacker break out of a container and own the host, and from there pivot across the subnet. Because the daemon typically runs as root, host-level hardening gaps translate directly into root-level blast radius. For a business that means production workloads, customer data and lateral movement into adjacent systems all hang off settings nobody reviewed after the VM was first stood up. CIS-aligned hardening shrinks that attack surface so a single weak default cannot escalate into an estate-wide incident.

How do I fix "Vulnerabilities in container security configurations should be remediated"?

  1. In Defender for Cloud, open Recommendations, filter to 'Vulnerabilities in container security configurations should be remediated', and select an affected host to list every failed CIS control with its remediation guidance; use Take action to open the prepared Log Analytics query.
  2. Harden the daemon on each host: restrict the Docker socket and TLS certificate file permissions, disable the legacy unauthenticated 2375 port in favour of TLS-protected 2376, avoid running containers with --privileged or the host network namespace, and enable user namespace remapping in /etc/docker/daemon.json, then restart the service so changes take effect.
  3. Because the legacy assessment is deprecated, move host hardening onto Azure Machine Configuration: enrol Linux VMs with the AzurePolicyforLinux guest configuration extension and assign the relevant baseline so secure settings are audited continuously and applied automatically. Look the definition up by display name rather than pasting a GUID, for example: pid=$(az policy definition list --query "[?displayName=='Linux machines should meet requirements for the Azure compute security baseline'].name" -o tsv); az policy assignment create --name docker-host-baseline --policy "$pid" --scope <scope>.

Remediation script · bash

RG=prod-rg
CLUSTER=prod-payments
SUB=$(az account show --query id -o tsv)

# 1. Restrict the API server to known networks (office egress + CI runners).
#    Use a private cluster instead where the public endpoint is not needed.
az aks update --resource-group "$RG" --name "$CLUSTER" \
  --api-server-authorized-ip-ranges "203.0.113.0/24,198.51.100.10/32"

# 2. Install the policy engine so guardrails are actually enforced in-cluster.
az provider register --namespace Microsoft.PolicyInsights
az aks enable-addons --resource-group "$RG" --name "$CLUSTER" --addons azure-policy

# For an Azure Arc-connected cluster, install the extension instead of the add-on:
# az k8s-extension create --name azurepolicy --extension-type Microsoft.PolicyInsights \
#   --cluster-type connectedClusters --cluster-name <arc-cluster> --resource-group "$RG"

# 3. Ratchet it shut: audit any future cluster missing the policy add-on.
#    Look the built-in policy up by its EXACT display name (never hardcode the GUID).
pid=$(az policy definition list \
  --query "[?displayName=='Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters'].name" -o tsv)
az policy assignment create --name audit-aks-policy-addon \
  --policy "$pid" --scope "/subscriptions/$SUB"

Full walkthrough (console steps, edge cases and verification) in the lesson Harden the AKS control plane.

Is "Vulnerabilities in container security configurations should be remediated" a false positive?

A purpose-built CI build agent that runs Docker in a short-lived, network-isolated VM may legitimately keep a setting the CIS benchmark flags, such as a non-default storage driver, and still flag here. If that host is ephemeral, isolated and rebuilt from a known image each run, document the exception in your hardening baseline rather than chasing the finding, and confirm the VM is excluded from any environment where it could reach production data.