I want to limit the access to one of my app services to Azure API Mangement. In order to be independent from a single IP I created the following setting using service-tag-based restriction:
However if I test my API using the Developer Portal I still receive 403 messages.
If I now add a restriction-rule to allow the IP address of the API Management it will work.
The documentation claims that service tags are adding the IP ranges for the provided Azure services to the restrictions. This is exactly what I want to achieve but it does not seem to work.
After I contacted the MS support I know can tell an answer to this.
On central message in the answer was
Unfortunately, there is no tag for all of the API Management outbound IP addresses.
The support highlighted that the documentation for service tags points out that
This enables customers to perform management operations on the APIs, Operations, Policies, NamedValues configured on the API Management service.
What this means is that the service tag is only for backend operations. Problem with this is that it doesn't help you at all. I already noticed that after I switched on the service tag rule I could not update an API using the direct OpenAPI endpoint via the portal which is the documented way. This is because the explorative request against the OpenAPI would be performed using the local browser as a XHR-request. This means I would have to add my local IP to the restriction list every time.
The supports suggests to put everything inside a VNET and configure the access using this technique. I had this solution in place and then considered it as too clumpsy. I guess I have to do it now.
Related
I am pretty new to Azure API Management so hopefully I am just missing the obvious and there is an easy solution.
I work in a regulated environment where strict validation and code separation is enforced.
For that reason an API that I wrote is implemented on four separate app services each representing a specific environment sandbox, dev,qa, and production
I am trying to set all these up in API Management using custom domains, but it just doesn't seem to work.
Here is where I am at.
API Management has been deployed to its own subnet in a vnet.
I created an internal client certificate, and uploaded it to a vault. This certificate had multiple subject name alternatives to represent each environment.
Ex. api.contoso.com
api-sand.contoso.com
api-dev.contoso.com
Etc
I then created custom domains using this certificate in APIM ...each set as a "gateway" type domain
I then created an Api based on api-dev.contoso.com and a suffix "external" based on the dev app service. This will host the dev operations that can be exposed to the internet through app gateway
I then created a second api, again using the api-dev.contoso.com custom domain, and specified a suffix of "internal", to host all the internal operations from this api.
I ran into trouble when I tried to create a third API. This one was supposed to target the sandbox version of the api, but when i started filling out the new api panel, I found that the base url was grayed out and set to api-dev.contoso.com.....there was no way to change it to api-sand.contoso.com
What am I missing?? ...APIM let's you create these custom domains, but it seems to only let you use one...that doesn't seem right....there must be a different approach I need to use.
One option I thought of, but haven't tried yet is to have one custom domain, and implement the environments using different suffixes. For example api-nonprod.contoso.com/sand/external would link to my sandbox app service, and api-nonprod.contoso.com/dev/external would link to the development app service.
I'd still rather do it through custom domain names if it is possible.
We are looking at using webhooks from various vendors outside our network. They would publish the event to us. We would be the webhook listener/receiver, not pushing the events. We have done proof of concept of creating an Azure Function to receive the event. From the research we have done most have the security of passing a sha1/sha256/sha512 hash for us to verify they are who we want to receive the events. This all worked as expected with the POC Azure Function.
From a enterprise network security standpoint is there anything else available? The process above puts the security in the function. I'm sure our Network Security group would not want us to have 10 functions, one for each vendor to worry about the security. I've read about whitelisting of IP's that would be sending the events but most of our vendors are Cloud based so I'm not sure how readily that would be available. Maybe one function to validate all events that come in then let pass through? Would that be an acceptable solution? Azure API Gateway or API Management able to address somehow? Any other network type of product that handles webhook security specifically?
Any insight or link to information most appreciated.
Thanks.
Wow, that's really really so open conversation.
You can use Azure Front Door with the Web Application Firewall attached to it. So any SQL injection, DDoS or similar attacks can be prevented by AFD and WAF.
However, I would say the securest way is to put IP restriction as well. So you need to force your vendor to get their IP address. That can be multiple maybe hundreds. But that doesn't matter. You can implement CIDR IP address format so you can cover all network. And you can easily set these IP address restriction during the CI/CD pipeline with Azure PowerShell script.
You can also useAPI Management in front of Azure Functions and you can create access restriction policies. You can either restrict IP based or JWT based. APIM might be a little bit pricey tho.
https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies
You can also create advanced policies with APIM
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies
Apart from that, the AFD & WAF and IP restriction are on the network layer. But you can also implement token-based authentication on your code side.
https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization
You can either you Azure Active Directory, IdentityServer or JWT for this.
Good luck!
We've implemented a setup as follows:
App Service Environment having different app services exposing different APIs. This instance is configured as an internal instance, so no public access.
We've configured an internal (private) DNS zone. This zone is used to create internal URLs for the API's.
API Management instance which is exposed to the outside. Here the API's need to be registered using the Swagger files exposed by the APIs themselves.
Everything is contained within the same VNet.
Now what we see is two things:
From a VM inside the VNet, I can browse the URL of the API without any issue and download the Swagger file.
When we try to register the API within API management, it throws an error stating the file could not be downloaded. When we register manually and then try to call the API, we get a DNS resolve error.
So it seems as if the API Management instance is not able to resolve our custom DNS zone as setup in Azure. I could not find any information that tells me whether this scenario is supported or not. Any pointers that might help find the problem are very welcome indeed.
Update when we register the API via uploading a file and then try to call one of the API methods, the following error appears:
The remote name could not be resolved
This same address resolved just fine from a VM within the exact same VNet.
I have the same issue, when I look for online, the below solution looks promising. It is self-explanatory, DNS forwarded need to enable between vnets. More information is here
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server
Is there any way to secure an HTTP endpoint of an Azure Logic App ?
For example if I'm using my Logic App's HTTP request endpoint to be triggered as a webhook from a payment gateway, I'd want to restrict only certain static IP Addresses to access it and enable HTTPS.
I didn't find any firewall options like those present in Azure SQL for IP base restrictions.
You can put the manual trigger endpoint behind Azure API Management, using its "Restrict caller IPs" policy should help you accomplish what you need.
See https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app
Restrict incoming IP addresses
In addition to the Shared Access Signature, you may wish to restrict calling a logic app only from specific clients. For example, if you manage your endpoint through Azure API Management, you can restrict the logic app to only accept the request when the request comes from the API Management instance IP address.
This setting can be configured within the logic app settings:
In the Azure portal, open the logic app you want to add IP address restrictions
Click the Access control configuration menu item under Settings
Specify the list of IP address ranges to be accepted by the trigger
A valid IP range takes the format 192.168.1.1/255. If you want the logic app to only fire as a nested logic app, select the Only other logic apps option. This option writes an empty array to the resource, meaning only calls from the service itself (parent logic apps) fire successfully.
I could be wrong but all App Services (Web Apps, Logic Apps, API Apps) are, by default, publically accessible and, by default, do not enable IP Filtering via Azure resource configuration (meaning, a setting on the Logic App). Options I can think of enabling this would be:
If you have access to a Web.config, use an element to restrict traffic to only a specific set of address (see MSDN)
Consider putting the Logic App behind an API Management resource and enforce a IP restriction policy (see Azure API Management Documentation); I'm guessing this may not apply for Logic Apps but including it anyway
Scale to a Premium App Service Plan, deploy Logic App to an App Service Environment which gives you the ability to specify whether there is a Public IP (VIP) used for load balancing requests or internal load balancer (which would be used for cross-premise connectivity between your LAN and Azure); you can also deploy a virtual Web Application Firewall (WAF) which would allow you to place explicit IP filters as well
Not knowing your requirements, I'd lean more towards option 3 simply because there is documentation supporting that scenario (at least for Web, Mobile and API Apps -- Logic Apps are not mentioned). Otherwise, if you're not able to modify the web.config to include the filters and cannot put an API Management instance in front of the logic app, I'm not sure what other options you may have.
Hope this helps and if you find a solution, I'd be interested in learning it as well.
I am implementing OData using ASP.NET Web API 2.2. These are deployed as Azure Web roles in different Azure Data centers where data is present in SQL Azure DBs. If there is a request coming from the user, the request has to be redirected to a particular web role deployed in based on the user details.
I am still exploring Azure Traffic Manager capabilities. Is it the way to do it in Azure? or what is the right approach for such scenarios in Azure?
This is not possible using Azure Traffic Manager. Traffic Manager simply does DNS resolution based on the policy (perf, round robin, failover) you choose.
If you want to intelligently route customers based on some logic then I would suggest:
First, are you sure you want to do this? A key tenant of a highly scalable and available service is that a request can be served by any instance/deployment, and it is more important to get the request to the fastest deployment (ie. the perf profile for WATM). There are valid reasons to need to direct users to a specific service, but I would suggest taking a hard look at this design requirement.
You could use ARR or URL Rewrite to internally fetch data from the correct deployment. This may have perf implications, but would be easy to implement.
As Brendan mentioned in a comment, you could have a thin web API layer that just does a 302 redirect to send the user to the correct deployment.