AKS | HTTP Proxy Support


Azure Kubernetes Service (AKS) clusters, regardless of whether they’re deployed in a managed or custom virtual network, require specific outbound dependencies to operate effectively. Previously, in environments where internet access had to be routed through HTTP proxies, this presented a challenge. Nodes lacked the means to bootstrap the essential configuration, environment variables, and certificates needed to connect to internet services.

With this newly introduced feature, AKS clusters now support HTTP proxies. This provides a user-friendly interface for cluster operators to manage network traffic required by AKS in environments dependent on proxies, ensuring a secure and smooth operation.

Example of Json HTTP Proxy Config File:

  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
  "trustedCa": "string"

Create a new AKS cluster with HTTP proxy configured on the nodes:

az aks create -n $clusterName -g $resourceGroup --http-proxy-config aks-proxy-config.json

Update an existing HTTP proxy:

az aks update -n $clusterName -g $resourceGroup --http-proxy-config aks-proxy-config-2.json

Note: ods must be rotated for the apps to pick it up. For components under kubernetes, like containerd and the node itself, this won’t take effect until a node image upgrade is performed.

The following scenarios are not supported:

  1. Varied proxy configurations for each node pool
  2. User/password authentication
  3. Custom Certificate Authorities (CAs) for API server communication
  4. Windows-based clusters
  5. Node pools utilizing Virtual Machine Availability Sets (VMAS)
  6. Employing ‘*’ as a wildcard appended to a domain suffix for noProxy

Additionally, it’s important to note that by default, both httpProxy and httpsProxy, as well as trustedCa, are unset.

Resource: https://learn.microsoft.com/en-us/azure/aks/http-proxy#updating-proxy-configurations


Azure Resource Graph Policy Exceptions 


I’m excited to share that you can now harness the power of Azure Resource Graph to effortlessly retrieve all policy exceptions. This is made even more seamless with the introduction of the new field: microsoft.authorization/policyexemptions.

Example: Extract all the policies which expire within 90 days

PolicyResources | where type == 'microsoft.authorization/policyexemptions' | extend expiresOnC = todatetime(properties.expiresOn) | where isnotnull(expiresOnC) | where expiresOnC >= now() and expiresOnC < now(+90d) | project name, expiresOnC

Example: All the policies exceptions per assignment

PolicyResources | where type == 'microsoft.authorization/policyexemptions' | summarize count() by tostring(properties.policyAssignmentId)


ACR | Containers vulnerability assessment powered by Microsoft Defender Vulnerability Management (MDVM)


Enhanced by Microsoft Defender Vulnerability Management (MDVM), the Azure Vulnerability Assessment is an effortless, plug-and-play solution, empowering security teams to swiftly identify and rectify vulnerabilities within Linux container images. This process requires no initial configuration for onboarding and eliminates the need for agent deployment.

Notably, this feature exclusively supports the scanning of images within the Azure Container Registry (ACR). Images stored in alternative container registries must be imported into ACR for coverage.

MDVM-powered Container Vulnerability Assessment boasts the following key capabilities:

  • Scanning OS Packages: This feature allows for the scanning of vulnerabilities present in packages installed by the OS package manager in Linux. Refer to the comprehensive list of supported OS and their versions for further details.
  • Language-Specific Packages: Support is extended to language-specific packages and associated files, along with their dependencies, whether installed or copied without the involvement of the OS package manager. For a complete list of supported languages, please consult our resources.
  • Image Scanning in Azure Private Link: This capability enables the scanning of images within container registries accessible through Azure Private Links. It is contingent upon access to trusted services and authentication with the registry. Learn how to enable access through trusted services.
  • Exploitability Insights: Each vulnerability report undergoes scrutiny within exploitability databases, assisting customers in gauging the actual risk associated with each reported vulnerability.
  • Comprehensive Reporting: Container Vulnerability Assessment for Azure, powered by Microsoft Defender Vulnerability Management (MDVM), furnishes vulnerability reports with the following recommendations:
    • Querying Vulnerability Information via Azure Resource Graph: This functionality facilitates the querying of vulnerability information through the Azure Resource Graph. Find out how to query recommendations via ARG.
    • Querying Vulnerability Information via Subassessment API: Obtain scan results through the REST API.
    • Support for Exemptions: Learn to create exemption rules for a management group, resource group, or subscription.
    • Support for Disabling Vulnerabilities: Gain insights into disabling vulnerabilities on images.

One-Time Triggering:

  • Each image pushed or imported to a container registry undergoes scanning immediately after the operation. Typically, the scan concludes within minutes, but may occasionally extend up to an hour.
  • [Preview] Images pulled from a registry are scheduled for scanning within 24 hours.

Microsoft Defender Vulnerability Management (MDVM) now incorporates an additional trigger for scanning images retrieved from an ACR. This enhancement extends coverage to active images, complementing existing triggers for scanning images pushed to an ACR within the last 90 days and images currently operational in AKS.

Continuous Rescan Triggering:

A continuous rescan is vital to ensure that images, previously scanned for vulnerabilities, receive updates to their vulnerability reports in the event of a newly discovered vulnerability.

  • A rescan is executed once daily for:
    • Images pushed within the last 90 days.
    • [Preview] Images pulled within the last 30 days.
    • Images currently active on the Kubernetes clusters monitored by Defender for Cloud, either via agentless discovery and visibility for Kubernetes or the Defender agent.