Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
Attention: All Microsoft Defender for Cloud features will be officially retired in Azure in China region on October 1, 2026 per the announcement posted by 21Vianet.
This article lists all the container security recommendations you might see in Microsoft Defender for Cloud.
The recommendations that appear in your environment are based on the resources that you're protecting and on your customized configuration. You can see the recommendations in the portal that apply to your resources.
Tip
If a recommendation description says No related policy, usually it's because that recommendation is dependent on a different recommendation.
For example, the recommendation Endpoint protection health failures should be remediated relies on the recommendation that checks whether an endpoint protection solution is installed (Endpoint protection solution should be installed). The underlying recommendation does have a policy. Limiting policies to only foundational recommendations simplifies policy management.
Microsoft Defender for Cloud performs vulnerability assessment for container images and running containers across supported environments. Findings are surfaced as individual security recommendations in Defender for Cloud, generated based on the cloud provider, resource type (container registries or running containers), and the enabled Defender plans. Rather than relying on a fixed set of recommendations, Defender for Cloud dynamically evaluates container workloads and images and presents the relevant recommendations in the Recommendations experience, where they can be filtered and prioritized based on risk and scope. This approach ensures that vulnerability assessment results remain accurate and up to date as new environments, threats, and capabilities are introduced.
Azure container recommendations
Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed
Description: Azure Policy extension for Kubernetes extends Gatekeeper v3, an admission controller webhook for Open Policy Agent (OPA), to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner. (No related policy)
Severity: High
Type: Control plane
Azure Arc-enabled Kubernetes clusters should have the Defender extension installed
Description: Defender's extension for Azure Arc provides threat protection for your Arc-enabled Kubernetes clusters. The extension collects data from all control plane (master) nodes in the cluster and sends it to the Microsoft Defender for Containers backend in the cloud for further analysis. (No related policy)
Severity: High
Type: Control plane
Azure Kubernetes Service clusters should have Defender profile enabled
Description: Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender profile on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more in Introduction to Microsoft Defender for Containers. (No related policy)
Severity: High
Type: Control plane
Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed
Description: Azure Policy add-on for Kubernetes extends Gatekeeper v3, an admission controller webhook for Open Policy Agent (OPA), to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner. Defender for Cloud requires the Add-on to audit and enforce security capabilities and compliance inside your clusters. Learn more. Requires Kubernetes v1.14.0 or later. (Related policy: Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters).
Severity: High
Type: Control plane
Azure registry container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)
Description: Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. Resolving vulnerabilities can greatly improve your security posture, ensuring images are safe to use prior to deployment. (Related policy: Vulnerabilities in Azure Container Registry images should be remediated).
Severity: High
Type: Vulnerability Assessment
Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)
Description: Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. This recommendation provides visibility to vulnerable images currently running in your Kubernetes clusters. Remediating vulnerabilities in container images that are currently running is key to improving your security posture, significantly reducing the attack surface for your containerized workloads.
Severity: High
Type: Vulnerability Assessment
Container CPU and memory limits should be enforced
Description: Enforcing CPU and memory limits prevents resource exhaustion attacks (a form of denial of service attack).
We recommend setting limits for containers to ensure the runtime prevents the container from using more than the configured resource limit.
(Related policy: Ensure container CPU and memory resource limits do not exceed the specified limits in Kubernetes cluster).
Severity: Medium
Type: Kubernetes Data plane
Container images should be deployed from trusted registries only
Description: Images running on your Kubernetes cluster should come from known and monitored container image registries. Trusted registries reduce your cluster's exposure risk by limiting the potential for the introduction of unknown vulnerabilities, security issues, and malicious images.
(Related policy: Ensure only allowed container images in Kubernetes cluster).
Severity: High
Type: Kubernetes Data plane
(Enable if required) Container registries should be encrypted with a customer-managed key (CMK)
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of the contents of your registries. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at Overview of customer-managed keys. (Related policy: Container registries should be encrypted with a customer-managed key (CMK)).
Severity: Low
Type: Control plane
Container registries should not allow unrestricted network access
Description: Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific public IP addresses or address ranges. If your registry doesn't have an IP/firewall rule or a configured virtual network, it will appear in the unhealthy resources. Learn more about Container Registry network rules at Configure public IP network rules. (Related policy: Container registries should not allow unrestricted network access).
Severity: Medium
Type: Control plane
Container registries should use private link
Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your container registries instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/acr/private-link. (Related policy: Container registries should use private link).
Severity: Medium
Type: Control plane
Containers sharing sensitive host namespaces should be avoided
Description: To protect against privilege escalation outside the container, avoid pod access to sensitive host namespaces (host process ID and host IPC) in a Kubernetes cluster. (Related policy: Kubernetes cluster containers should not share host process ID or host IPC namespace).
Severity: Medium
Type: Kubernetes data plane
Container with privilege escalation should be avoided
Description: Containers shouldn't run with privilege escalation to root in your Kubernetes cluster. The AllowPrivilegeEscalation attribute controls whether a process can gain more privileges than its parent process. (Related policy: Kubernetes clusters should not allow container privilege escalation).
Severity: Medium
Type: Kubernetes data plane
Diagnostic logs in Kubernetes services should be enabled
Description: Enable diagnostic logs in your Kubernetes services and retain them up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs. (No related policy)
Severity: Low
Type: Control plane
Immutable (read-only) root filesystem should be enforced for containers
Description: Containers should run with a read only root file system in your Kubernetes cluster. Immutable filesystem protects containers from changes at run-time with malicious binaries being added to PATH. (Related policy: Kubernetes cluster containers should run with a read only root file system).
Severity: Medium
Type: Kubernetes data plane
Kubernetes API server should be configured with restricted access
Description: To ensure that only applications from allowed networks, machines, or subnets can access your cluster, restrict access to your Kubernetes API server. You can restrict access by defining authorized IP ranges, or by setting up your API servers as private clusters as explained in Create a private Azure Kubernetes Service cluster. (Related policy: Authorized IP ranges should be defined on Kubernetes Services).
Severity: High
Type: Control plane
Kubernetes clusters should be accessible only over HTTPS
Description: Use of HTTPS ensures authentication and protects data in transit from network layer eavesdropping attacks. This capability is currently generally available for Kubernetes Service (AKS), and in preview for AKS Engine and Azure Arc-enabled Kubernetes. For more info, visit https://aka.ms/kubepolicydoc (Related policy: Enforce HTTPS ingress in Kubernetes cluster).
Severity: High
Type: Kubernetes Data plane
Kubernetes clusters should disable automounting API credentials
Description: Disable automounting API credentials to prevent a potentially compromised Pod resource to run API commands against Kubernetes clusters. For more information, see https://aka.ms/kubepolicydoc. (Related policy: Kubernetes clusters should disable automounting API credentials).
Severity: High
Type: Kubernetes Data plane
Kubernetes clusters should not use the default namespace
Description: Prevent usage of the default namespace in Kubernetes clusters to protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types. For more information, see https://aka.ms/kubepolicydoc. (Related policy: Kubernetes clusters should not use the default namespace).
Severity: Low
Type: Kubernetes data plane
Least privileged Linux capabilities should be enforced for containers
Description: To reduce attack surface of your container, restrict Linux capabilities and grant specific privileges to containers without granting all the privileges of the root user. We recommend dropping all capabilities, then adding those that are required (Related policy: Kubernetes cluster containers should only use allowed capabilities).
Severity: Medium
Type: Kubernetes data plane
Microsoft Defender for Containers should be enabled
Description: Microsoft Defender for Containers provides hardening, vulnerability assessment and run-time protections for your Azure, and hybrid Kubernetes environments. You can use this information to quickly remediate security issues and improve the security of your containers.
Remediating this recommendation will result in charges for protecting your Kubernetes clusters. If you don't have any Kubernetes clusters in this subscription, no charges will be incurred. If you create any Kubernetes clusters on this subscription in the future, they'll automatically be protected and charges will begin at that time. Learn more in Introduction to Microsoft Defender for Containers. (No related policy)
Severity: High
Type: Control plane
Privileged containers should be avoided
Description: To prevent unrestricted host access, avoid privileged containers whenever possible.
Privileged containers have all of the root capabilities of a host machine. They can be used as entry points for attacks and to spread malicious code or malware to compromised applications, hosts, and networks. (Related policy: Do not allow privileged containers in Kubernetes cluster).
Severity: Medium
Type: Kubernetes data plane
Role-Based Access Control should be used on Kubernetes Services
Description: To provide granular filtering on the actions that users can perform, use Role-Based Access Control (RBAC) to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies. (Related policy: Role-Based Access Control (RBAC) should be used on Kubernetes Services).
Severity: High
Type: Control plane
Running containers as root user should be avoided
Description: Containers shouldn't run as root users in your Kubernetes cluster. Running a process as the root user inside a container runs it as root on the host. If there's a compromise, an attacker has root in the container, and any misconfigurations become easier to exploit. (Related policy: Kubernetes cluster pods and containers should only run with approved user and group IDs).
Severity: High
Type: Kubernetes Data plane
Upgrade Azure Kubernetes Service to remove vulnerabilities from AKS system pods
Type: Upgrade Azure Kubernetes Service Version
Description: Defender for Cloud scans AKS-managed system pods for known vulnerabilities (CVEs). When vulnerabilities are detected, this recommendation identifies the minimum AKS version upgrade that resolves each CVE, giving you a clear and actionable remediation path. This recommendation applies to system pods managed by AKS, not customer workloads. For each CVE, the recommendation lists CVSS score, and the minimum AKS version that includes the fix. (No related policy)
Severity: High
Type: Vulnerability Assessment
Data plane recommendations
All the Kubernetes data plane security recommendations are supported for GCP after you enable Azure Policy for Kubernetes.
External container registries recommendations
Container images in Docker Hub registry should have vulnerability findings resolved
Description: Defender for Cloud scans your registry images for known vulnerabilities (CVEs) and provides detailed findings for each scanned image. Remediating vulnerabilities in container images helps maintain a secure and reliable software supply chain, reduces the risk of security incidents, and ensures compliance with industry standards."
Severity: High
Type: Vulnerability Assessment
[Preview] Container images in Jfrog Artifactory registry should have vulnerability findings resolved
Description: Defender for Cloud scans your registry images for known vulnerabilities (CVEs) and provides detailed findings for each scanned image. Remediating vulnerabilities in container images helps maintain a secure and reliable software supply chain, reduces the risk of security incidents, and ensures compliance with industry standards.",
Severity: High
Type: Vulnerability Assessment