Forum Widgets
Latest Discussions
Defender for Cloud Container Workloard AWS EKS
Hi, We're onboarding an AWS environment with EKS clusters into Defender for Cloud. The AWS connector is configured correctly and everything up to the final step works: the clusters are discovered and visible in the portal, Defender creates its access entries, authenticates into the clusters, and actively polls them (agentless coverage is healthy). However, the Azure Arc onboarding never initiates. The "Auto provision Defender's sensor for Azure Arc" component is enabled, but Defender never issues the Microsoft.Kubernetes/connectedClusters/write — the Azure Activity Log shows zero attempts of any status, so no connectedCluster is ever created, no azure-arc/mdc namespaces appear, and the Defender sensor is never deployed.
LAW Architecture for Security Center
There are two options how to set up the LAWs for the Security Center. By default, when onboarding the subscription in the Security Center, a separate LAW is created for each subscription. Microsoft also allows you to define your own (central) LAW. Which option should be considered considering to have security logs and monitoring/performance logs? What is the difference? Can I give a Log Analytic Agent two different destinations (one for ASC Security Logs and one for Azure Monitor Logs)?
Exempt - Azure CSPM Recommendation
We are implementing creating exemptions on policies through Terraform. Is there a way to exempt this specific Azure CSPM standard policy "Restricted network access should be configured on Internet exposed Function app" through Terraform since it does not have any policyassignmentid and policyid. I think this standard policy cannot be exempted with this code. Please confirm. My understanding is this is Assessment type and has no policy id or policy assessment id. I can exempt through Azure Portal but not from Terraform. Any guidance is greatly appreciated. resource "azurerm_subscription_policy_exemption" "this" { for_each = local.subscription_exemptions name = each.key subscription_id = each.value.resource_id policy_assignment_id = each.value.policy_assignment_id policy_definition_reference_ids = each.value.policy_definition_reference_ids exemption_category = each.value.category expires_on = each.value.expires_on description = "Ticket: ${each.value.ticket} | ${each.value.remediation_plan}" metadata = jsonencode(merge(var.tags, { owner = each.value.owner ticket = each.value.ticket risk_level = each.value.risk_level remediation_plan = each.value.remediation_plan approved_by = each.value.approved_by approval_date = each.value.approval_date environment = var.environment managed_by = "terraform" })) } Thanks, AnshuExempt a specific container in MDC
You don't need a full exemption for this — the built-in policy behind "Immutable (read-only) root filesystem should be enforced for containers" already supports per-container and per-image exclusions natively, which is more precise than exempting at the resource/cluster level. This recommendation is implemented via the Azure Policy Add-on for Kubernetes (Gatekeeper constraint) as part of Defender for Cloud's data plane hardening. The underlying policy definition supports these parameters: excludedContainers — exclude by container name excludedImages — exclude by image (supports prefix matching, e.g. myregistry.azurecr.io/legacy-app:*) excludedNamespaces — exclude entire namespaces (e.g., kube-system, useful for system pods that legitimately can't run read-only) To configure: Defender for Cloud → Recommendations → select this recommendation → Take action tab, where you can set these parameters directly without touching raw policy JSON. Alternatively, if you manage policy via Environment Settings → Security policies → Standards, you can set the same parameters on the standard assignment. Given you said multiple containers across airflow/db1, airflow/sql1, etc. show "Unhealthy" — if these are legitimate exceptions (e.g., a database container that needs to write to its filesystem by design, not just a misconfiguration), excludedContainers naming each container is the cleanest fix and keeps the recommendation enforcing everywhere else in the cluster. I'd reserve a full policy exemption (Azure Policy exemption resource) for cases where you need it tracked for compliance/audit purposes specifically — the parameter-based exclusion is the more "native" and maintainable fix for ongoing operational cases like this.Exempt - Azure CSPM Recommendation" (Terraform exemption
The reason you're not finding a standalone policyAssignmentId/policyDefinitionId for this specific recommendation is that it isn't a standalone assignment — it's one control inside the built-in CSPM initiative (the "ASC Default" / Microsoft Cloud Security Benchmark assignment). That initiative does have an assignment ID; you just need to target the specific control within it, not look for a separate one. In azurerm_resource_policy_exemption (or the subscription/resource-group variants), the relevant fields are: policy_assignment_id → the ID of the initiative assignment (ASC Default / MCSB), not a per-recommendation assignment policy_definition_reference_ids → an array scoping the exemption to just this one control instead of the whole initiative resource "azurerm_resource_policy_exemption" "function_app_network_exemption" { name = "exempt-function-network-restriction" resource_id = azurerm_linux_function_app.example.id policy_assignment_id = data.azurerm_subscription_policy_assignment.asc_default.id policy_definition_reference_ids = [ "<reference-id-for-the-specific-control>" ] exemption_category = "Waiver" # or "Mitigated" if an equivalent control exists expires_on = "2026-12-31T00:00:00Z" } To find the policy_definition_reference_id for this specific control: in the Azure Portal, go to Policy → Definitions, search for "Restricted network access should be configured on Internet exposed Function app" to get its definition ID, then open the initiative definition (ASC Default) and find the matching entry in its policyDefinitions[].policyDefinitionReferenceId array — that string is what goes in the array above. Two things worth deciding upfront before automating this: Waiver vs Mitigated — if you've genuinely restricted access another way (e.g., Private Endpoint), use Mitigated so it's distinguishable from accepted risk in reporting. Consider whether the exemption belongs at the resource scope (just this Function App) vs resource group/subscription — narrower is safer, but if you have a pattern of similar apps, a tagged-based resourceSelectors block can scale this without per-resource blocks.Exempt a specific container in MDC
I have this recommendation showing in defender. Immutable (read-only) root filesystem should be enforced for containers There are multiple containers inside AKS that are showing as "Unhealthy" airflow/db1 airflow/sql1 airflow/scheduler1 Is there a way to exempt a specific container or the whole recommendation has to be exempted. Thanks
Microsoft.Security/policies GET endpoint returning 404 — deprecated? What is the replacement?
Hi, We are using the Azure Security Center REST API (api-version=2015-06-01-preview) to retrieve security policies for a subscription. We are hitting a 404 Not Found error on the Get endpoint while the List endpoint works fine. Looking for clarification on whether this resource type has been deprecated and what the modern replacement is. --- Endpoints in use List Security Policies (WORKING): GET https://management.azure.com/subscriptions/{subscriptionId}/providers/microsoft.Security/policies?api-version=2015-06-01-preview This returns a valid JSON response with an array of policies, each having an id, name, type, and a properties object containing policyLevel, recommendations, pricingConfiguration, securityContactConfiguration, etc. Get Security Policy by Name (BROKEN): GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/policies/{policyName}?api-version=2015-06-01-preview --- Error received Not Found for url: https://management.azure.com/subscriptions/<sub-id>/resourceGroups/AzureEventHubIT-resource-group/providers/Microsoft.Security/policies/AzureEventHubIT-resource-group?api-version=2015-06-01-preview HTTP Status: 404 Not Found --- What we've observed - The List endpoint works and returns policies whose id values follow this exact structure: /subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/microsoft.Security/policies/{policy-name} - The policy name in the List response matches the resource group name (1:1 mapping), so we are passing the correct value to the Get endpoint. - Despite using the exact name and resource group from the List response, the Get endpoint returns 404. - We also checked the https://learn.microsoft.com/en-us/rest/api/defenderforcloud/operation-groups?view=rest-defenderforcloud-2015-06-01-preview and noticed that Security Policies does not appear as a documented operation group in any version — including 2015-06-01-preview. The only documented groups for that version are: Discovered Security Solutions, Locations, Operations, and Tasks. --- Questions 1. Has the Microsoft.Security/policies resource type at the resource group scope been officially deprecated or removed? If so, is there a migration guide or announcement? 2. Why does the List endpoint still respond successfully while the individual Get endpoint returns 404? Is the List endpoint returning legacy/cached data? 3. What are the recommended replacement APIs for the functionality that was in the old policies resource? Specifically we need equivalents for: - properties.pricingConfiguration → Is this now covered by https://learn.microsoft.com/en-us/rest/api/defenderforcloud/pricings/get?view=rest-defenderforcloud-2024-01-01? - properties.recommendations (patch, antimalware, diskEncryption, etc.) → Is this now https://learn.microsoft.com/en-us/rest/api/defenderforcloud/assessments?view=rest-defenderforcloud-2020-01-01? - properties.securityContactConfiguration → Is this now Microsoft.Security/securityContacts (2020-01-01-preview)? 4. Is there any announced retirement date for the List endpoint as well? Any official documentation links or migration guides would be very helpful. Thank you.Onboarding MDE with Defender for Cloud (Problem)
Hello Community, In our Customer i have a strange problem. We onboarded with Azure Arc server and activate a Defender for Cloud servises only for Endpoint protection. Some of this device onboarded into Microsoft Defender portale, but not appears as a device, infact i don't have opportunity to put them into a group to apply policy. I have check sensor of Azure Arc and all works fine (device are in Azure Arc, are in the defender portal and see them on Intune (managed by MDE)). From Intune portal From Defender portal But in difference from other device into entra ID exists only the enterprise application and not device I show the example of device that works correctly (the same onboarding method) Is there anyone who has or has had this problem? Thanks and Regards, Guido
