would appreciate some assistance.
I have an single enrolment with two subscriptions
Subscription A (with several vents e.g. A1, A2, A3)
Subscription B (with several vents e.g. B1, B2, B3)
I am avoiding the VPNs and VNET peering due to company policies (treat each subscription like a separate entity)
In Subscription B, Azure Files and SQL will be used which Subscription A (A1, A2, A3) need to access and vice versa
We are looking into using public endpoints for Azure SQL and Azure Files (SMB), then locking down the access via firewall rules. This does cause issues with the public endpoints and I will looking at other options other then VPN and VNET peering about securing this communication.
I do appreciate that data between Subscription A and Subscription B will be via the Azure backbone as all service are in the same region.
Could Private Links be used there?
thanks
Could Private Links be used there?
As per the Microsoft official document:
In Azure, Private Link allows you to access Azure PaaS Services like Azure Storage, SQL Database and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.
So, as per the above statement, the Private Links also work in the Virtual Network only.
To make a secure connection between two Azure services which are either in same or different subscription, you can use combination of VNet and Firewall settings.
The VNet doesn’t combine the services but only allows us to communicate with each other. Your resources will be considered as a separate entity only.
In the File share side, you can use Firewall for specific client IP address along with Allow Azure services on the trusted services list to access this storage account feature. You can also route specific endpoints. Refer below image.
On the SQL side, to access public networks, you can choose Public network access option and allow only selected networks to access the server.
Along with that, you should also opt for Allow Azure services and resources to access this server.
Related
Right now we have multiple resources like storage accounts and key vaults where the team is using the firewall setting within the networking tab on the individual services. This means when their ip changes after a disconnect/connect to the company VPN they have to go in to each service and add their new IP address.
Not being well versed in Azure networking possibilities, what are some of the options we have to allow a group of incoming IP addresses to be able to access all these services without having to individually touch each service to add their new ip address?
All services are also on the same virtual network.
Thank You
I used to work on Azure Cloud services as a DevOps in the past.
There should be multiple ways to control incoming network traffic to your landing zone or azure resources. But you should consider your requirements meet the solution.
Here are few you could take a look at which I used:
Virtual network service endpoints
Azure Firewall
Network Security Groups
ExpressRoute
If I am setting up an Azure SQL Database in a vnet which Azure App Service and Azure Function will access. Is using both Subnet Delegation and Service Endpoints the right way to go? I didn't fully understand the documentation.
Regarding subnet delegation, I read this Microsoft article and this stackoverflow post, which stated:
When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner.
That sounds like a good thing but makes me wonder how it worked efficiently w/o subnet delegation.
As for Service Endpoints, I read this Microsoft article, which states:
Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Service Endpoints enables private IP addresses in the VNet to reach the endpoint of an Azure service without needing a public IP address on the VNet.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
They both sound like they have the same benefits and I'm struggling to understand the difference. I suppose the larger question is should I enable both for the simple architecture outlined above.
In the Microsoft service endpoints documentation they also mention:
Microsoft recommends use of Azure Private Link for secure and private access to services hosted on Azure platform. For more information, see Azure Private Link.
For some reason that seems like an Azure to on-premise thing.
• You cannot use a ‘Subnet Delegation’ along with a ‘Private endpoint’ since that subnet is delegated for the said service, in your case, the Azure SQL Database. Through a subnet delegation, you can define the NSG association for it, as well as associate multiple delegated subnets to a common NSG. You can also define the IP Address space for the delegated subnet, the route table association with it, the custom DNS entry configuration in Azure DNS as well as define the minimum number of IP Addresses available for that delegated subnet. Similarly, with regards to service endpoint, these stated functions are not available.
• In service endpoint, you do not have control over the routing mechanism as well as the IP address related allotment, reservation, or configuration. Also, managing DNS entries for the resources managed through them and controlling them through a firewall or NAT gateway isn’t required unlike a subnet delegation because all these things are managed by Microsoft Azure’s backbone network on your behalf.
Thus, both have their own features and specifications for enabling you to configure according to your own requirements.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
Yes, you will have to create a firewall rule to allow the access from on-premises system to Azure SQL Server/Database and configure the service endpoint accordingly to allow the VPN client IP Addresses for accessing the same over public internet.
Also, through Azure private link, you won’t be able to connect from on-premises to Azure as it uses a private IP address and a private DNS zone entry related to it to connect to Azure resources in the same virtual network.
To know more regarding the configuration of Azure service access from on-premises network, kindly refer to the below given link: -
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview#secure-azure-service-access-from-on-premises
Also, refer to the below snapshots regarding the configuration and selection of service endpoint for a particular subnet: -
Until now I assumed that the traffic flowing between 2 azure resources (say between an Azure VM & Storage Account or a Key Vault) was through the internet, if private and service endpoints are not configured. But today a colleague of mine shared an article where it says that all the traffic between the Azure datacenters does not go through the internet, it's on Microsoft's backbone network only. Link to the article - https://azure.microsoft.com/en-in/blog/how-microsoft-builds-its-fast-and-reliable-global-network/
Now there could be 2 things:
Either the article is now outdated (it is from 2017) and no longer true, and w/o any special configuration the traffic between 2 azure resources flows through the internet, or,
The traffic indeed flows through the Microsoft's network and not through the internet, but in that case, what's the benefit of Private endpoint apart from the fact that we can assign a private IP to a PaaS service.
Any insights in this regards would be highly appriciated. Thanks in Advance!
Yes all the traffic which is between Azure services travels over Microsoft backbone network.
This is documented here
Yes, any traffic between data centers, within Microsoft Azure or between Microsoft services such as Virtual Machines, Microsoft 365, XBox, SQL DBs, Storage, and virtual networks are routed within our global network and never over the public Internet, to ensure optimal performance and integrity.
Service endpoints provide an extra layer of isolation and security , as per Microsoft Docs :
Network connections can only be initiated by clients connecting to the private endpoint. Service providers don't have routing configuration to create connections into service consumers. Connections can only be established in a single direction.
To understand the private endpoints in better way I would recommend to read more about Private Link Service as well.
The difference is that services with Private Endpoint are not reachable from anywhere else but your VNet.
If you have an VM -> Storage without private endpoint, the traffic will go over the MS network, but your storage endpoint is public (I can reach it from my laptop :) )
If you place your storage in a VNet with private endpoints, then I need to be able to access the VNet in order I can reach the storage endpoint
I need to configure Azure SQL Database firewall settings so that it can only be accessed by my Azure Function app. The problem is I'm running the app in a consumption plan, and as far as I know, the outbound IP address(es) can change even when I don't take any actions.
Is there a way to whitelist the app so that I protect the database from unwanted connections?
I thought of whitelisting by Azure region since everything is hosted in the same region, but then how do I guard against other apps in the same region? That's why I'm thinking of using specific IP addresses. My only concern with this approach is, I don't know if other function apps can share the same outbound IP addresses as my own.
P.S. Currently, my firewall settings deny public network access and allow Azure services to connect only.
There are several ways to achieve this.
You may want to integrate VNet or get static IP addresses for your Azure Functions
Image from: https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options
However, what I've seen from your comments you don't want to go the premium plan.
The last thing I can suggest you implement Managed Service Identity.
The idea behind this, instead of connecting the database with connection string, you connect to the database with the access token that you granted. You can't get the access token if you are not in the same Identity.
This tutorial explains the general idea with App Service:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi
and this tutorial pretty much covers what do you really want to achieve.
https://www.azurecorner.com/using-managed-service-identity-in-azure-functions-to-access-azure-sql-database/
Good luck!
I had the same issue but managed identity didn't make much difference.
In the firewall setting for the SQL server there is an option to allow azure resources to access the server. For me this was set to no, but needed to be set to yes.
One thing you can do is assign a managed identity to your function. It will retrieve a token from Azure AD, and it will be used to connect to Azure SQL:
if (accessToken != null) {
string connectionString = "Data Source=<AZURE-SQL-SERVERNAME>; Initial Catalog=<DATABASE>;";
SqlConnection conn = new SqlConnection(connectionString);
conn.AccessToken = accessToken;
conn.Open();
}
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-sql
You can do this by assigning a static IP to the function app and whitelist at the SQL Server -INbound Networking side and Deny all requests. However you have to change the consumption plan to Appservice to assign a static IP.
https://learn.microsoft.com/en-us/azure/azure-functions/ip-addresses#dedicated-ip-addresses
Also, you can try creating a Vnet peering for those services and block other requests.
I can't find where i got the answer (so not my answer but sharing it here), your Azure Functions have a list of outboundIpAddresses and possibleoutboundIpAddresses that you can add to your Azure SQL firewall rules (mine had about 10).
You can find them by...
Go to https://resources.azure.com
Expand Subscriptions -> [Expand your Subscription] -> Providers -> Microsoft.Web -> Sites
Find your Azure Function Site in the JSON, and locate the outboundIpAddresses and possibleoutboundIpAddresses, these will contain a list of IP addresses.
Add all of them to your SQL server's firewall.
While I'm not positive if these will ever change, so far they haven't for me and the person who originally posted this solution also noted that they haven't run into issues with this.
Virtual networks do not work on Azure the same way as they work on premises
If you create a vnet, add your Azure function in a subnet and in sql server you allow this subnet to access it will unfortunately not work.
If it is ok for you to allow "public access" and/or "azure resources access" then things are simple. You log in with sql credentials and you have access.
If you block public access I am not sure that your resources would be able to access your database, because all your connection go to SQL server from the internet not from your internal network.
Solution that worked for me is
Create a vnet
Create a private endpoint for Sql server in this vnet (custom DNS records were created by the IT-OPS people).
Azure function uses a subnet of this vnet.
Now, you can close public and azure resources access in your database.
All your calls will go through your virtual network (not through the internet anymore) and only applications that use a subnet of this vnet would be able to connect to the database.
So we are starting to move to the cloud and our biggest concern is security, as it should be. The thing that I am not sure about is how to secure the end points from public (interent) access? Is this even possible or is there something else we can do to keep the environments in Azure out of the public eye?
This question is likely better suited to server fault. But until then...
In Azure IaaS V1, you can specify IP based ACLs (access control lists) to restrict inbound traffic.
In both IaaS v2, you can leverage NSG (network security groups) to help restriction trick into and out of specific VMs or virtual network sub-nets.
If you are using Azure Express Route (a leased line into an Azure facility), the VMs can be addressed directly from within the virtual network connection and don't need to have publically exposed endpoint.
Then there's also all the usual options such as securing the connections on the VMs themselves. :)
If you are using Azure Resource Groups along with your VMs (which is available on the new portal) you cannot use endpoints because it's not available there, so you should do the following to open up the HTTP port or ANY other port:
(Sign in to your account on the new portal)
1- Select the VM that you want to manage ports on.
2- In settings, click on Network Interfaces and select your network.
3- Go to Network Security Group and select your group.
4- Add Inbound or Outbound security rules depending on what you need.