*** Update: The below update to Network Isolation settings enforcement and the addition of AMPLS flags will be release by end of August, 2021 ***
Azure Monitor Private Links are used extensively, to provide a direct, private connection between customer VNets and their monitoring resources - Log Analytics workspaces and Application Insights components. We continuously see more customers and more traffic going to Private Links, and with it also a need to improve how it is controlled and applied to networks and resources.
Starting mid-August, we'll roll out two improvements intended to help you both onboard private links, and use it as best fits your needs.
Note that networks deploying new Private Link setups after this date will default to a new, open behavior, allowing these networks to reach non-private-link resources as well!
Until now, Azure Monitor Private Links acted mostly as "All or Nothing" - it required organizations to onboard all their resources to Private Links, or none at all. Customer feedback showed us that this requirement made onboarding too difficult, and also wasn't truly required for all customers. Many customers wish to use Private Links for some resources, but not limit their Azure Monitor traffic to Private Links alone.
Starting August 16, 2021, we'll have new controls to allow you to choose how Private Links should apply to your networks:
While using the open mode, you get these Private Link benefits -
However, to fully protect your network and set handle the risk of data exfiltration (org data leaking out), use the Private Only mode, allowing your network to access only specific resources, through a Private Link. External resources won't be reachable to assure your logs remain within the boundaries you set. Before you switch to the Private Only mode, make sure to carefully map your Azure Monitor resources (Log Analytics workspaces and Application Insights components) and add them to the AMPLS. And remember - close your firewall, to make sure only your client on your network can only use Private Links.
These new settings can be set on the AMPLS to apply to all networks connecting to it, or even for specific networks (using the Private Endpoint Connections on the AMPLS). Note they are split between ingestion and query to give you the flexibility you may need. Initially you'll be able to set these settings through ARM templates, policies, CLI and REST calls, and later we'll support configuration through the Azure Portal.
You may already be able to see the new settings on your AMPLS JSON but will only be able to set them after August 16.
Creating a new AMPLS object will require you to provide your preferences (Open or Private Only, for ingestion and for queries). It will not have default values. We recommend using the Private Only mode cautiosly - while it is most secure and protects from data exfiltration, it also means traffic to resources not in the AMPLS will fail, across all networks that use share the DNS server, and regardless of subscription or tenant. We'd therefore recommend to start with the Open access mode, and switching to Private Only after adding all resources to the AMPLS. Using the Open mode means a Private Link will be used when possible (i.e., when the target resource is connected to an AMPLS) but won't drop requests to resources out of the AMPLS, as long as these resources accept queries/ingestion from public networks.
Existing setups keep their existing behavior, which is:
You can of course change these settings on your existing environment to fit your needs.
Azure Monitor resources have Network Isolation settings that allow them to block queries and log ingestion from public networks (meaning the requests aren't sent over a Private Link). We found that in some cases users chose to block traffic from public networks without connecting the resource to an Azure Monitor Private Link Scope (AMPLS). That effectively meant the resource isn't accessible both publicly and privately. While this configuration is valid, in many cases it's a simple mistake.
Our query mechanism treated this configuration as invalid, and therefore only blocked queries from public networks if the resource was associated with an AMPLS. Starting August 16, 2021, resources that block queries from public networks will stop accepting public queries, even if they're not associated with any AMPLS. Please make sure your workspaces and components don't block queries from public networks without connecting to an AMPLS for Private Link access.
In order to avoid configuration errors, the Network Isolation page has been updated to show clearer messages and also alert when users set an irregular configuration.
In addition, we're also alerting on irregular settings through a new banner, notifying you to review your Network Isolation configuration and avoid unintentionally blocking queries.
We appreciate your feedback! comment on this blog post and let us know what you think of the this feature.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.