I want to enable traffic from my webapp (that sits inside the VNET and has its private IP) to Application Gateway (that is deployed to the same VNET and has NSG attached to its subnet).
How can I do it?
If I add webapp outbound ip to NSG as allowed - traffic works fine, but I do not want to hardcode this ip.
If I add "Internet" service tag it works as well, but it is too broad for my taste.
I could not find any other relevant service tags for me (tried "AppServiceManager", "AppService" and "AppService.AustraliaEast").
Also checked this document (and had to update the filename to last Monday! :) ) but could not find the IP that worked for me (52.187.231.76).
Ideal solution would be to allow only VNET traffic, but this did not do the trick as well... All ServiceEndpoints are there.
Checked with Azure support. Unfortunately there is no service tags available to do this yet.
Workaround - to manually add security rules for each application that supposed to access Application Gateway to allow Outbound IPs.
To do so - go to azure portal, to the application that needs to be able to access App GW. Go to properties blade and copy Outbound IP addresses. Then go to NSG and create a new inbound security rule to allow access from all of those IPs (at least it can be 1 rule).
According to Azure support those IPs should not change unless you recreate the whole webapp and the app can only cycle through those IPs.
Related
I'm trying to secure my containerized web app with a Premium V2 App Service Plan. I've enabled Service Endpoints for an integration subnet for the different App Services to restrict incoming traffic from each other except for the frontend (so all of them are integrated with the VNet and all have incoming traffic restricted to that VNet except for the frontend).
I have also other Azure services like Azure Functions or a Storage Account that can have inbound traffic restricted by using those Service Endpoints. However, One of the App Services calls an external 3rd party API that lies on Azure too. That API may or not be behind a static IP. However, it has a Custom Domain associated.
The problem arises when I try to connect to that API from one of the VNet integrated App Services. As the destination IP is inside one of the IP ranges that are added to the routing with the use of a Service Endpoint, traffic is sent via that Service Endpoint instead of simple Azure routing. I've tried overriding the route with a Route Table associated to that subnet but that seems not to be possible, with or without a NAT Gateway attached to the subnet. I guess Azure routing is prioritized here. I'm sure the route is not effective as I used it on a different subnet where I deployed a VM.
Is there any way I can use that Service Endpoint for my internal traffic only so it's not used when it goes to an Azure hosted API or I need to switch to a different approach like Private Endpoints or an ASE?
I am unsure what you're looking for but if you want to explicitly define routes you should try using app services setting "WEBSITE_VNET_ROUTE_ALL" = 1 which overrides the default precedence of routing and makes sure that every outbound call follows the route defined inside route table of subnet.
Use the following steps to add the WEBSITE_VNET_ROUTE_ALL setting in your app:
Go to the Configuration UI in your app portal. Select New application setting.
Enter WEBSITE_VNET_ROUTE_ALL in the Name box, and enter 1 in the Value box.
When WEBSITE_VNET_ROUTE_ALL is set to 1, outbound traffic is still sent from the addresses that are listed in your app properties, unless you provide routes that direct the traffic elsewhere.
We've been able to ask the 3rd party to disable blocking rules. It turns out they had a rule that blocked this specific traffic.
I already tried changing that setting, but didn't try putting a route table on it. However, it'd make no difference as I can't define a list of allowed outbound IPs belonging to Azure since we have no static IP to call.
I've got an azure sftp container instance properly set up finally but I ran into a wall while configuring security for it (much like the person here).
My basic flow is this:
PIP on Azure ->
-> Load balancer using PIP to be reached by the wider web ->
-> Load balancing rule to backend subnet ->
-> SFTP container group living on that subnet ->
-> SFTP container in that group
Nothing special and I verified before associating the NSG that the network is operating as intended. Connection to the SFTP server is functioning properly. The problem is, after associating the NSG with the container group's subnet, I was still able to connect to it without any configured rules. Even after applying a rule # priority 100 to deny all traffic, to rule out something I may miss from the default rules, I can still get in.
After reading how NSG flow logs don't include container instances, I'm torn between believing users have NSGs working with container groups but are missing logs, and the possibility that NSGs don't work with container groups at all. If anyone has any guidance on properly using NSGs here, please let me know. Otherwise, if there's another tool I should be using, please recommend it (Azure Firewall is included in the container group tutorial, but I believe completely overkill for what I need and also prohibitively expensive).
EDIT: Adding picture of NSG rules -
After my validation, currently, the NSG associated with the ACI subnet does not work in this scenario for the SFTP container service behind an Azure load balancer. This NSG rule does not block the client's public IP address and it works like without it.
As a workaround, you could restrict the SFTP access with NGINX reverse proxy like this blog or add a service like Azure Application gateway reverse proxy to direct your public-facing traffic to your backend instance.
I am trying to solve a problem. I have to access APIs that are hosted on my on premises server (on-prem) from Azure hosted Web API.
The problem is that my on-prem server only allows white listed IPs. I know we can get outbound IPs from our Web App (Azure hosted). But I am not sure whether they are static or will change based on scaling.
Another Solution is to create VNET and add that Web app into that VNET. But I would like someone to suggest better solutions.
There are couple of choices you have.
First, you can have a look at the possibleOutboundIpAddress of your App Service and whitelist this IPs. This however also opens up the door for IPs not really in use by your App Service.
az webapp show --resource-group <group_name> --name <app_name> --query possibleOutboundIpAddresses --output tsv
Secondly, you can put a NAT Gateway in-front of your App Service. This however requires an App Service Plan that supports virtual network integration.
Configure regional virtual network integration from within your app service.
Force all outbound traffic originating from that app to travel through the virtual network. This is done by setting WEBSITE_VNET_ROUTE_ALL=1 property in your web app configuration
Create a public IP address.
Add a NAT gateway, attach it to the subnet that contains the app service and make use of the public IP created in step 3.
If you would also like to use a static inbound IP you can find more information here
The outbound IPs for Azure App service are generally static and will not change on scaling. There are normally 4 outbound IPs and they only change if you change the SKU or there is a need at MS end to increase the capacity of their data center (rare or may never happen in near future).
I would recommend creating a VNET as that is more secure than whitelisting IPs at your on prem service. But if you want to want list the outbound IPs, I would recommend creating a wrapper for your on prem APIs in Azure and whitelist IPs for these in your on prem firewall. This will ensure that you don't have to whitelist every time you want to create an API in Azure that needs to access on prem APIs.
Unfortunately there is no straight forward way to do this in Azure for App Services, I also had this issue recently.
The only solution (for now anyway) is to add the list of outbound IPs of the App Service to your allow rules.
Just be careful with scaling between the tiers because it will change the outbound IP addresses. (https://learn.microsoft.com/en-us/azure/app-service/overview-inbound-outbound-ips#when-outbound-ips-change)
The simplest way would be to use an Azure VM with a static public IP which is used for both inbound and outbound.
Sam Cogan has a good blog post where he does go through a couple of options.
(https://samcogan.com/obtaining-a-static-outbound-ip-from-an-azure-virtual-network/)
A hybrid connection might be a solution https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections? I think they are designed for accessing on premise services.
I have an ILB ASE v2 with WAF (public IP). The ASE has its subnet where all web apps reside. For obvious security reasons I think I need to lock down access from Internet and leave only HTTPS open. But when I do that I can't see app services info in the portal. So what should my NSG look like for this subnet?
Also, WAF has its own subnet. It doesn't have NSG assigned either. Should it have one?
When you add a NSG to the AppSercice subnet with Deny All internet traffic, it is blocking the portal to fetch information from App Device. Try adding a NSG rule with greater priority with source IP as Azure Cloud tag and allow it.
So you are blocking all Internet traffic and allowing Azure IPs for communication.
Let me know if it works.
Here's the resulting rules set for ASE subnet NSG:
you might want to add HTTP to it if you need it.
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.