Azure / Enterprise-Scale

The Azure Landing Zones (Enterprise-Scale) architecture provides prescriptive guidance coupled with Azure best practices, and it follows design principles across the critical design areas for organizations to define their Azure architecture
https://aka.ms/alz
MIT License
1.72k stars 974 forks source link

💡 Feature Request - Add Network Isolation for Azure Monitor Logging #967

Open KenKilty opened 2 years ago

KenKilty commented 2 years ago

The ALZ-Bicep logging configures a shared service for logging for the tenant that is public facing (via Azure Monitor defaults). It would be helpful to have the ability to define an Azure Monitor Private Link Scope (AMPLS) and related Network Isolation configuration including switches for whether or not to accept data ingestion from public networks and queries from public networks.

Use Azure Monitor Private Link Scope (AMPLS) - Code Samples | Microsoft Docs

This capability would need have a dependency on the networking module which stands up the default Private Link Zones include I am not sure if inclusion into the existing module would make sense as this would create a dependency on the networking module. It may make more sense for a new logging-networkisolation module that accepted as input the following:

  1. Bool for ‘Accept data ingestion from public networks not connected through a Private Link Scope’
  2. Bool for ‘Accept queries from public networks not connected through a Private Link Scope’
  3. String target subscription and resource group for the AMPLS. Default resource group of ‘alz-logging’
  4. String for AMPLS instance name. Default to ‘alz-az-mon-pri-scope’ or similar.
  5. RID for the alz-log-analytics workspace to attach the scope too with configuration

The downside of taking this approach is there is now a need for an orchestrator so the alternative approach would be to accept all of the above as well as VNET details from the networking module.

jtracey93 commented 2 years ago

Migrating this issue to the upstream ESLZ/ALZ repo as this would need to be considered for all reference implementations (Bicep, Portal & Terraform) rather than just ALZ-Bicep.

This is so we have consistency and parity across all implementations instead of a customer having to choose a specific implementation option depending on what features it has available.

Hope that makes sense, we will triage this issue here first and asses if it is something we will consider adding to the implementations

KenKilty commented 2 years ago

This makes compete sense. Thank you.

jtracey93 commented 2 years ago

Trigger ADO Sync 1

jtracey93 commented 2 years ago

Trigger ADO Sync 2