Support local development using services behind firewall

[pakrym]

Some services (like Azure SQL) are not exposed to the internet by default. When developing an application that uses Azure SQL a firewall rule needs to be manually added to allow remote access.

It would be nice if azd was able to simplify this scenario somehow. One way might be to have a well-known parameter name DEV_EXTERNAL_IP and use it to conditionally populate the firewall rules in local dev scenarios.

[karolz-ms]

Having a parameter that allows traffic from a single IP to go through does not seem to be a flexible enough solution. Because of NAT, and as the developer is changing location, the IP that Azure SQL "sees" as the source of traffic might change unpredictably.

Here is what the baseline should be IMO:

1. In production the allowed traffic should come only from a set of well-known hosts that are part of the application. This is usually done via vnet settings.
2. In development the server should accept all properly authenticated traffic.

I am going to follow up with the Azure SQL team to see if they think the above is valid and what are their general thoughts on the use of the SQL firewall during development vs production.

If the above holds, our problem is not so much the firewall configuration for SQL Azure, but the fact that we haven't really embraced the idea of production-vs-development deployments. @jongio @markweitzel do we have a (design) issue for that?