Network access and permissions reference for Defender for Containers

This article describes the network connectivity and permission requirements for Microsoft Defender for Containers.

The requirements in this article depend on the enabled features and the environment in which your container workloads run.

Learn more about connectivity patterns.

Microsoft Defender for Cloud to container registries

Microsoft Defender for Cloud connects to container registries to scan container images for vulnerabilities. In some cases, Defender for Containers also publishes vulnerability assessment results back to the registry.

Azure Container Registry (ACR)

Network

  • For private ACRs, network access is automatically granted through Azure infrastructure.

Permissions

  • Role: Defender Container Registries
  • Permissions:
    • Microsoft.ContainerRegistry/registries/pull/read
    • Microsoft.ContainerRegistry/registries/metadata/read
    • Microsoft.ContainerRegistry/registries/read
    • Microsoft.ContainerRegistry/registries/repositories/content/read
    • Microsoft.ContainerRegistry/registries/repositories/metadata/read
    • Microsoft.ContainerRegistry/registries/catalog/read

JFrog Artifactory (SaaS)

Network

  • The JFrog Artifactory instance must be publicly accessible over the internet.

Permissions and configuration

  • A dedicated group, such as mdc-group-{customerTenantId}
  • A permission target with read access to all repositories for the MDC group
  • An OpenID Connect (OIDC) provider integrated with Microsoft Entra ID
  • OIDC identity mappings that allow authentication by using Entra-issued tokens

API scopes used

  • Group access: /access/api/v1/scim/v2/Groups
  • Permission targets: /access/api/v2/permissions (READ on ANY LOCAL, REMOTE, DISTRIBUTION)
  • OIDC provider and identity mappings:
    • /access/api/v1/oidc
    • /access/api/v1/oidc/{oidcName}/identity_mappings

Docker Hub (SaaS)

Network

  • Docker Hub must be publicly accessible over the internet.

Permissions

  • Customer-provided access token with read access

Microsoft Defender for Cloud to Kubernetes clusters

Microsoft Defender for Cloud connects to Kubernetes API endpoints to discover clusters and collect configuration data for posture and risk analysis.

Azure Kubernetes Service (AKS)

Network

  • No additional public or restricted public endpoint configuration is required. Microsoft Defender for Containers accesses the Kubernetes API through Azure Trusted Access.

Permissions

  • Managed identity created in the customer environment
  • Built-in role: Kubernetes Agentless Operator
    • Microsoft.ContainerService/managedClusters/read
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

Note

For AKS, Defender for Cloud uses AKS Trusted Access. Defender for Cloud creates a managed identity and a trusted access role binding. After the cluster is discovered, Defender for Cloud creates a Kubernetes ClusterRoleBinding to the built-in AKS ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator, which grants read permissions inside the cluster.

Amazon Elastic Kubernetes Service (EKS)

Network

  • Kubernetes API server must allow access from:
    • 172.212.245.192/28
    • 48.209.1.192/28
  • For private API endpoints, a restricted public endpoint must be enabled with the IP ranges above.

For private EKS clusters, the Kubernetes API server must expose a restricted public endpoint that allows access from the approved Microsoft Defender for Containers IP ranges.

Permissions

  • Role: MDCContainersAgentlessDiscoveryK8sRole
    • eks:UpdateClusterConfig
    • eks:DescribeCluster
    • eks:CreateAccessEntry
    • eks:ListAccessEntries
    • eks:AssociateAccessPolicy
    • eks:ListAssociatedAccessPolicies

Note

eks:UpdateClusterConfig is used to add the Microsoft Defender for Containers static IP CIDR blocks to the EKS cluster public access CIDR allowlist (ResourcesVpcConfig.PublicAccessCidrs). It's also used to update the authentication mode from CONFIG_MAP to API_AND_CONFIG_MAP, which is required for access entry creation on older clusters. If this permission isn't granted, inventory collection fails for clusters with restricted public endpoint access because Defender for Containers can't connect to the Kubernetes API server. Inventory collection also fails for clusters that use CONFIG_MAP-only authentication because Defender for Containers can't create the required access entries. For clusters with an open public endpoint, this permission isn't required for connectivity, but Defender for Cloud still attempts the configuration update.

Kubernetes clusters to Microsoft Defender for Cloud

Kubernetes clusters send runtime security data to Microsoft Defender for Cloud.

Outbound network requirements

  • Protocol: HTTPS
  • Port: 443
  • Domain: *.cloud.defender.microsoft.com

Kubernetes permissions created by the Defender sensor

The Defender sensor creates Kubernetes roles with the following permissions:

API group Resources Verbs
core ("") pods, nodes, services, events, configmaps get, list, watch, patch
apps daemonsets, replicasets, statefulsets, deployments get, list, watch
batch jobs, cronjobs get, list, watch
networking.k8s.io ingresses get, list, watch
apiextensions.k8s.io customresourcedefinitions get, list, watch, create, update, delete
defender.microsoft.com All resources (*) get, list, watch, create, update, delete

Cloud infrastructure to Microsoft Defender for Cloud (Kubernetes audit logs)

Defender for Containers requires Kubernetes audit logs for control plane threat detection.

Azure Kubernetes Service (AKS)

  • Audit logs are collected agentlessly through Azure infrastructure.
  • No additional network or permission requirements apply, including for private AKS clusters.

Related content

  • Last updated on