To access KV from AppGW, why do I have to allow VNet as well as allow trusted services?

Hello MartinHerbener-7973

When setting up Azure Application Gateway to use certificates from Azure Key Vault, these two key actions are required:

Adding Existing Virtual Networks:

This step allows the Application Gateway to securely communicate with the Key Vault.

By defining the virtual network and subnet, you establish the network boundaries for the Application Gateway, which is vital for security and access control.

Allowing Trusted Services to Bypass the Firewall:

This setting allows trusted Microsoft services, such as the Application Gateway, to access the Key Vault without being blocked by firewall settings.

While the Application Gateway is already a trusted service, this setting provides an additional layer of access, ensuring it can bypass firewall restrictions that apply to non-trusted services.

Note: If you do not allow these while adding the Key Vault certificate, sometimes the Application Gateway may go to a failed state.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

I know that is what is documented, but why is the "Allow Trusted Services to Bypass the Firewall" setting not sufficient? Is this a known defect that will get fixed? Or does the "Allow trusted Microsoft services" setting have some (apparently undocumented) limitations? I don't understand why that checkbox exists if it doesn't actually work as it seems like it should.

Hello @MartinHerbener-7973

At first glance, it may appear redundant. Let me clarify why both steps—adding the Virtual Network and enabling "Allow trusted Microsoft services to bypass this firewall"—are recommended in this case:

1. "Allow trusted Microsoft services" Scope: Enabling this setting allows certain Azure services, considered "trusted," to bypass the firewall restrictions on your Key Vault. Azure Application Gateway is indeed a trusted service, as you’ve pointed out in the documentation link. This means Application Gateway can access the Key Vault even if the Key Vault's firewall blocks other traffic.
2. Specific Virtual Network Requirement: When you add the Virtual Network (VNet) and subnet of your Application Gateway to the Key Vault, it ensures that any traffic coming specifically from that VNet is allowed. This offers an extra layer of control, especially in scenarios where you have multiple Application Gateways or network configurations. Associating the VNet explicitly ties the traffic to a known source within your architecture.

Why Both Steps Are Mentioned:

• The "Allow trusted Microsoft services" option is broad and applies to multiple Azure services. If you enable it, any Azure service marked as "trusted" may bypass the firewall (not just your Application Gateway). While this may simplify things, it might expose your Key Vault to more services than intended.
• Adding the VNet provides more granularity and control. By explicitly adding the VNet and subnet, you're ensuring that only the traffic from that specific Application Gateway in your network architecture can reach the Key Vault.

In summary, the combination of these steps offers both flexibility and precision:

• Use "Allow trusted Microsoft services" if you want an easier, broader setup.
• Add the VNet explicitly for tighter control and to follow best practices when implementing network security.

If security and strict access control are your priorities, it’s a good idea to use both settings together.

Kindly let us know if the above helps or you need further assistance on this.

Given this statement:

The "Allow trusted Microsoft services" option is broad and applies to multiple Azure services. If you enable it, any Azure service marked as "trusted" may bypass the firewall (not just your Application Gateway). While this may simplify things, it might expose your Key Vault to more services than intended.

Doesn't choosing "Allow trusted Microsoft services" mean that traffic from ANY VNet/subnet is allowed (assuming it's from a trusted Microsoft service) regardless of the chosen virtual networks?

Hi,

You wrote

Scenario 1 ... If a service that is not on the trusted list tries to access Key Vault privately without enabling the Trusted Services option, the access will be denied.

This is confusing. If the service is NOT on the trusted list, why would enabling the "Trusted Services" option allow access? I would think that enabling the "Trusted Services" option would only add access for trusted services?