How can we improve Azure Networking?

Allow Network Security Groups (NSGs) to Reference Application Security Groups (ASGs) From Different Location

Remove the limitation of restricting Network Security Groups (NSGs) ability to leverage/associate Application Security Groups (ASGs) that are not within the same location of the target Virtual Network (VNET).

This is especially important, to provide granularity and segregation/isolation in a hub-and-spoke networking model (i.e. VNetA-ASG1-to-VNetB-ASG1), in association with VNet Peering.

256 votes
Vote
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
You have left! (?) (thinking…)
Adin Ermie shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

14 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Oliver commented  ·   ·  Flag as inappropriate

    Team, do we have any updates for the expected timeline for this?

    Thanks

  • Giuseppe De Nicolò commented  ·   ·  Flag as inappropriate

    I agree that the ASGs are of limited use in the current state, they need to be able to traverse vnet peerings to be able to create some complex network design

  • Justin Turver commented  ·   ·  Flag as inappropriate

    Am assuming this is non-trivial to implement due to e.g. tagging on packets across logical segments, or implementing globally replicated objects of some kind, but it would make Azure network security more in line with on-prem options. Would be a huge uplift in agility and scalability in the network space. Ideally ASGs would span vnets, subscriptions and locations plus be consumable in that format in Azure Firewall rulesets. Hopefully any efforts to implement private routeable PaaS endpoints would also inherit that tagging capability in an easy to consume format.

  • Benjamin Mitchell commented  ·   ·  Flag as inappropriate

    Come on guys.. Currently Applications Sec Groups are mostly useless except in limited small deployments. The minute you try to build out a large scale, cross-regional solution, they become useless..

  • Anonymous commented  ·   ·  Flag as inappropriate

    Hi,

    Any update on this?
    Currently working on a project that it would be really useful for
    No cross site functionality will probably prevent us using NSGs

  • Chris commented  ·   ·  Flag as inappropriate

    In our environment, we want to deploy across 2 regions for redundancy, but the app servers in both sites will need to access the db servers at either site. They will be in the same subscription but I can imagine other scenarios where they may not be.

  • Christopher Gerard Quinn commented  ·   ·  Flag as inappropriate

    We have a complex hub, spoke-hub, spoke network topology to overcome the limitation on the number of VNET peers. We are trying to implement micro-segmentation and the ability to use application security groups between VNETs in the same region would greatly simplify that effort.

  • Romain HENRY commented  ·   ·  Flag as inappropriate

    Hi all !

    We encouter the same kind of issues in a hub and spoke architecture. I would like to authorize flows between VMs hosted in a subscription and some relays hosted in a transit subscription using "external" ASG and it's not possible.

    Can you remove this limitation ? This would be helpful to implement inter subscription dynamic filtering.

  • Andreas commented  ·   ·  Flag as inappropriate

    Indeed a very important request. Please also remember that in some hub and spoke designs we have to cross subscription boundaries as well!

    Workaround until then: Work with two rulesets instead of one. Eg. for outbound connection spoke to hub, set one rule on spoke NSG reducing source to spoke ASG and set another rule on hub NSG, reducing destination to hub ASG. This is ugly, but allows the use of ASGs for SRC and DST.

  • dean commented  ·   ·  Flag as inappropriate

    We need ASG accessible over vnet peers so we can scale to a full hub and spoke network

Feedback and Knowledge Base