I have a application running on a AKS Container and would like to use the Azure Cosmos DB for storage. How can i set this up?
I think i just need to specify the ip address from which the requests are originating on the k8s cluster so that the cosmosdb will allow access.
Should this traffic go over the internet or is it possible to set up a connection between the vnets?
To connect to CosmosDB easiest way is to just use SDK provided by Microsoft in your app. You just provide your app a connection string to your database, here is a simple quickstart example. You don't have to open any network traffic on CosmosDB side if you use default configuration, but of course if you wish you can lock access to only selected networks. So if your containers have internet access they can also access your database.
To address your second concern to not go over internet you can get more information here.
To allow access from existing virtual network using portal you need to go to the cosmosdb resource into firewall tab and add existing network, you should see something like this:
Related
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.
While configuring an Azure managed Postgres service, I am trying to configure connecting from local machines through VPN.
I can connect to the DB when white-listing IPs in Connection Security.
I have added the subnet the VPN-gateway is connected to to the VNET Rules – this doesn't seem to make a difference.
I can connect to VMs through the VPN from my local machine.
However to make that work, I added the VMs' (private IP, Azure URL)-pairs to my local machines hosts-file.
I can't find any IP for the DB-service (which seems to make sense for a managed service), so I can't make the same trick.
The error I'm getting, when trying to connect to the DB, is similar to the ones I got before adding hosts mappings.
This all leads me to believe I need some way of having Azure resolve the URL (which might also preempt the need for hosts-mappings in general).
From this article, I tried setting my DNS for 168.63.129.16, but that doesn't work at all (nothing at all is resolved).
Is there a way (and if so, how) to connect from a local machine to an Azure Database for Postgresql service through a VPN gateway?
I don't think there is a way to do this as your desired. You want to map an Azure database logical server private IP to your local hosts file, then access it via VPN gateway.
You only know the public IP for the Azure database server. The public IP addresses of Azure services change periodically. You could find an IP address list by filtering your region. It does not recommend to use such a dynamic IP address. Refer to this blog.
Since Azure database is a fully managed Platform as a Service (PaaS) Database Engine not IaaS like Azure virtual machines, It's public and does not expose the database server private IP address. We only could access the database via Azure database server name over the Internet.
Furthermore, if you want to restrict its access only from a private network with virtual Network service endpoints. However, this works to allow resources like Azure VM in the authorized subnet to access directly your Azure database in a private network, could not guarantee that if you could access the Azure database from your local machine via VPN. This seems no on-premise route to your Azure database.
We are setting up SQL Always On in Azure VM (IAAS). We followed the steps given in Configure Always On Availability Group in Azure VM manually and the setup is working fine. Since the setup is using the internal load balancer, the listener is available only internally i.e. using a jump box. We are using NSGs to restrict access to the servers from our office IPs and allow access to the SQL Servers from developer machines. This works for direct access to the individual SQL server but not via listener. What can be done to allow access from outside of the VNET?
This subscription is standalone and not connected to the on-premise via site-to-site VPN or Express Route. The resources should be accessed using internet and source IPs are specifically white listed (it is a very small fixed list).
You can configure a Point-to-Site connection to allow your clients to connect the Azure VNet then use sql server.
Yes, the solution to which is to use a Point-to-Site with a VPN gateway deployed.
But, keep in mind that you can have a max of 128 users.
Apart from which, P2S should do the trick here.
I'm trying to enable Azure DocumentDB firewall by enabling the "Enable IP Access Control".
I managed to allow connections from my App Service. However the webjobs that reside on the app service does not have access to the Azure DocumentDB.
Is there a way to allow web job access to the DocumentDB?
thanks
Is there a way to allow web job access to the DocumentDB?
In short, no.
If we want to enable firewall blocked access policy, we need to add the allowed list of IP addresss or IP address ranges.We can get more info from document. But the Azure WebApp IP is not static.
all of access to your Azure Cosmos DB database account from machines outside the configured allowed list of IP address ranges are blocked
I managed to allow connections from my App Service
If it is meaning that you have turn Allow access to Azure Portal on.
If it is that case, it doesn't mean that we can access DocumentDB from Azure other services, it means that we can peform operations on the collections or docuemtns within account from azure portal.
Without portal access enabled, you will not be able to perform any operations on collections or documents within this account from the portal
In summary, if we want to allow web job access to the DocumentDB then we need to
trun Enable IP Access Control off. Or we could use Azure cloudservice or virtual machine to instead of WebJob.
Edit:
According to your comment, if we want to use the same IP as WebApp, we could use the outbound IP, we can get them from the azure resources(https://resources.azure.com/) then add the outboundIpAddresses to the DocumentDB allowed IP list. Then webjob could access to the DocumentDB.
Note: The outboundIpAddresses are not static ips, they may be changed when we restart the WebApp or change WebApp service plan.
If I create a VNet named mySiteToSitevNet and configure it for Site-To-Site connectivity. I create a Virtual Machine assign it to use mySiteToSiteVNet as its network. I Install SQL Server on it.
Do i get Public IP to connect to that SQL Server from my WebApp which does not have VNet associated to it?
If not, how do I make my WebApp connect to that SQL Server and use the database?
There are 2 options:
Since you already have a Sign to Site VPN then you can VPN in from your website's box to enable it to access the SQL and that's the most secure way.
If for some reason you don’t want to VPN in, first you need to figure out why you don’t want to do this. If there’s a really good reason to not VPN in, then continue with setting up direct Internet access to the SQL Server.
To open an endpoint browse to the VM in the Azure portal. Open the properties of the VM in the Azure Portal, then click the “All Settings” option. Then select “Endpoints”. It’ll look something like this.
If you see a “SQL Server” endpoint with 0 ACL Rules then the work is half done (shown above). If there are ACL rules then you should be finished unless you need to add more ACL Rules.
If there is no SQL Server endpoint click the “Add” button at the top of the Endpoints blade. Name the endpoint “SQL Server”, select the protocol TCP, then set the ports to 1433 (or whatever TCP ports you want to use, but 1433 is the default). Select to setup access rules for whoever needs access and block any subnets that don’t need access and then OK back to the VM’s properties.
At this point you can connect to the SQL Server instance through whichever method you’ve setup. If you are using either VPN option you can just connect to the Virtual Machine’s network name. If you are going through the public endpoint (again this is REALLY NOT recommended) you’ll need to connect to the machines full DNS name.
Any VM deployed in a Virtual network can also be exposed through public Internet, so the answer to your question is Yes, it can be given a instance lvel public IP address (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/) or port behind the public load balancer (https://azure.microsoft.com/en-us/documentation/services/load-balancer/)