Suppose I have an Azure function on Consumption plan hosted in VNET, if my function calls are restricted to the App Service Instance in the VNET, do I still need to ensure my function is only accessible with Function/Admin keys?
My view is that, if the endpoints are secured in VNET, then I do not need to implement access keys right?
I doubt we will be able to answer this question, it depends on your workload and security requirements.
One factor (network firewall) might be enough for your use case, others may want/need a second factor (authorization key).
Related
I have an Elasticsearch cluster that I need to access using an Azure Functions App. The current way to access it is via an IP whitelist. I've created my consumption plan Azure Functions and noticed that the IP address kept changing and after further research found that I'd need to whitelist the whole Azure Cloud which is not a secure option in our case. So I've upgraded Azure Functions to Premium plan and thus the VNet Integration appeared in the app settings allowing me to create a Virtual Network and a static Outbound IP Address.
Now it is working.
But since I'm using the Premium plan and the other mentioned services, the cost went up.
I've experimented with Azure Data Factory in the past and there was an option to install a local Integration Runtime so when ADF was accessing Elasticsearch via the Local Integration Runtime, it worked. Is there something similar I can use with Azure Functions? Like a Data Gateway I can install on a local server that is already whitelisted on Elasticsearch and all I'd need to do is connect from Azure Functions through it?
I guess the ideal scenario I'm looking for is to be able to use a Consumption Plan on Azure Functions.
Kind Regards,
Andrei
Just to close this one, in the end, I've used a Standard AppSevicePlan (S1) (costs $74|£51/month or about $2.5|£1.7/day). I've had to create a static Outbound IP, a NAT Gateway (which costs about another $30|£23/month or $1|£.77/day) and a VNET.
The tutorial can be found here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-how-to-use-nat-gateway
Another option that I've considered to reduce cost was to use a Hybrid Connection which would install a sort of gateway to a local server to which Azure Functions would connect first before reaching the ES endpoint...that would eliminate the need for the Outbound IP, NAT Gateway and VNET (so $30 less per month) but would still require at least an S1...so no option on consumption-based, and I don't know if there is any charge associated with this. However, we didn't go with this option as we want to eliminate any local dependencies (e.g. if the server where the gateway is running would shut down).
To sum up, use an S1, follow the tutorial mentioned above and should cost about $104|£74/month
I have a resource (specifically, a Kubernetes service deployed to my AKS cluster) to which I want to limit access. I've looked around through the MSDN documentation on What is Azure Virtual Network?, VPN Gateway design, and more, but I don't see a clear way that I can either:
Require AAD authentication before a specific IP/Port is accessed, or
Whitelist access coming from a specific IP/subnet (eg, specifying CIDR format www.xxx.yyy.zzz/nn that should get access).
There seem to be ways to restrict access that require I install some a RADIUS VPN client, but I don't want to require this. It seems like there are a ton of hoops to jump through -- is there a way I can block all incoming traffic to my AKS cluster except from specific AAD roles or from specific IP ranges?
It would be helpful to understand what you intend to use AKS for (web site, batch computing, etc.)
First you should fully explore the networking options offered by the service itself. Start with locking down to your personal IP address and the service will likely (based on Azure docs) append a deny-all to the end of your networking rules. To get the IP address it sees you from, try IP Chicken.
I offer two additional options: Application Gateway or API Management.
One way to lock this down, based on the information you shared, is Application Gateway.
Application Gateway (Product Page)
Ingress Controller for AKS
"Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the ingress for an Azure Kubernetes Service (AKS) cluster." - from Azure Docs
API Management
You also have API Management paired with policies on that resource. It can restrict by AAD (check pricing tier for details) and IP address (on any pricing tier).
If the organic networking options of AKS don't cover your use case, I would choose API Management. Price and options are better for what it seems you are aiming for.
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.
I have certain azure resources like AKS, redis, cosmos, APIM etc. To secure the resources from attacks like DDOS, we put them all in private vnet and made them accessible only via APIM. Is that the right approach? In this case we only need to worry about the security of APIM. However the cost associated with vnets are high and we are evaluating other options. One thing I see is DDOS protection plan which protects the whole RG. So another approach is to remove the VNET and make the RG protected with the DDOS protection plan. However, are there any other attacks which are possible even with DDOS protection plan? Whats the best way to address them? Any leads will be very helpful
you could use service endpoints for cosmos and restrict access only from vnet. For aks you can use loadbalanceripranges construct of k8s to whitelist ip's from api gateway.
Can we create a firewall rule in azure to allow connections from azure data centre ONLY?
Strictly speaking, this can't be done.
Fundamentally, Azure doesn't reside within a singe IP address range, nor does each Azure region. In fact, each region is broken into multiple address ranges which aren't necessarily concurrent. The ability to define a single firewall rule (which covers the entirety of Azure's infrastructure) would require some work in Azure to define, and maintain, a variable which holds all of these values.
It may be worth pointing out that Azure does already offer similar solutions for Internet and VirtualNetwork, which are applied in the default NSG rules. As the majority of infrastructure within Azure, but outside of your virtual network, is essentially the Internet, setting such a variable for all Azure IPs would give a user the option to, potentially unknowingly, open up their resources to any kind of malicious activity.
Depending upon what exactly it is you are attempting to achieve, Azure does offer workarounds in the form of Service Endpoints. This functionality has recently left the preview phase, and allows a user to create a security rule between certain PaaS resources and your virtual network. Currently, this functionality is restricted to Azure Storage, Azure SQL Database and Azure SQL Data Warehouse.
An extremely sloppy way of implementing firewall rules for all Azure IP ranges would be to manually enter the address ranges from the region(s) you require, which can be downloaded here. However, doing this would be highly discouraged due to security flaws previously mentioned, plus these IP ranges are not entirely static, therefore it would be easy to get caught out if Microsoft was to edit certain address ranges.