I have an Azure Static Web App developed using Angular (let's say my company homepage) which needs to be publicly accessible w/o authentication. If I wanted some dynamic content on the home page which comes from a database (i.e. news items or a product list), are there any ways to "secure" an Azure Function endpoint that supplies this data to the front end.
"secure" == I'd like to limit access of the endpoint to just my Azure Static Web App.
I'd also like to set up a function that listens for IPN requests from PayPal and so I'd like to configure that function to only be accessible from PayPal.
I see that I can configure CORS to only allow specific domains access to a function -- is this my best option?
There are two ways to look at it,
(i) Azure has APIM Service which allows to secure certain endpoints and is probably the best way how to handle Azure Functions endpoints for public.
(ii) You can also secure the functions by adding application gateway and whitelist the IP address of the Application gateway in the function or you can build functions inside a vnet using the azure environment service.
You can read more about Securing Azure Functions here
Related
I have Azure app service (Web API) and have restricted access to everyone and allowed access by Ipaddress using access restrictions (https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions)
I want to allow a particular domain/endpoint access to the API doesn't matter which IP address they are coming from. Is there any way possible to do it.
Unfortunately, It's impossible to whitelist a particular domain/endpoint to the Azure app service using access restrictions as essentially the domain name will be resolved to a real IP address via DNS when the client access the web API in the Azure app service.
Not sure why you want to only allow a particular domain. Perhaps, you just want to map a custom domain to Azure App Service. Then you can access the web API using your multiple custom domain URLs.
Furthermore, optionally, you could apply an Application gateway in front of your web API, then you could access your backend web API using a custom domain URL or Application gateway URL. Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example, URI path or host headers. Also, you could whitelist the Application gateway frontends in your app service access restrictions. See Configure App Service with Application Gateway for more details.
I hope it's helpful for you.
In a typical 3-Tier web app, you run web servers in public subnet, while app tier lives in private subnet. Is it possible to run similar architecture with Azure Web apps and Api apps?
I guess you can run Asp.NET Core Web App in Azure Web App and Deploy AspNet Core Web Api to Azure Api App, then make Api end point private so only Web app can talk to it? I see options like Google, Facebook et. as auth providers. Is that what you have to do to make API private?
D.
If you want that level of isolation, one (although expensive) option is an App Service Environment (ASE). Link to docs: https://learn.microsoft.com/en-us/azure/app-service-web/app-service-app-service-environment-intro
App Service Environments are ideal for application workloads requiring:
Very high scale
Isolation and secure network access
The public environment where you deploy by default is public. Your endpoints will be accessible to anyone anywhere, and it is up to your app to do the filtering. This can be done, e.g. through static IP address security settings in Web.config. The problem with that is that even then you can't know for sure what IP address your front-end will use for communication. There are multiple possible addresses it may use for outbound traffic, and those are subject to possible change.
You can see an example of IP restrictions here: restricting IP security
Of course you should also have authentication set up on your API. Documentation links:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://learn.microsoft.com/en-us/azure/app-service-api/app-service-api-authentication
In line with what #juunas said above and a slight variant is to introduce Azure API Management Gateway in between Azure web app and Azure Api app. In standard tier API Gateway the IP address is fixed and doesn't change and you can use the API Gateway address in Azure API App web.config to whitelist.
We have a API-based microservice system, where a public API gateway (.NET Nancy API running on Azure Website) calls into microserviced API's (various technologies) to return data.
Currently, the microserviced API's are either Azure WebSites, or Azure Functions (HTTP trigger), so that means they have a public endpoint, with HTTP exposed to the public. (e.g https://my-microservice.azurewebsites.net)
Is there any way to lock this down so that only the API gateway can call into it?
I've read about DIPR but that seems to be based on a public IPv4 address (i don't think we can get a static IP for the API gateway?).
Currently we make the microserviced API's require authentication via bearer tokens (using IdSrv auth server), but ideally i'd like to secure the API's at the network level, then remove the token/IdSrv dependency. Can we leverage VNET's?
How do other people solve this? As in, how can we lock down an Azure Website from public access?
TIA.
You should use Azure Virtual Network and create rules for inbound/outbound traffic (valid for Standard / Premium App Service Plans): https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-integrate-with-vnet
There's also Azure App Service environment for that, however it requires a Premium App Service Plan: https://learn.microsoft.com/en-us/azure/app-service-web/app-service-app-service-environment-intro
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'd like to implement micro service architecture on CF (run.pivotal.io) and have problems with creating my private backend services.
As I see I have to options at deployment: with and without route.
With route my services becomes public which is ok for my public site and my public REST API, but I don't want it for my backend services.
Without route I don't see how should I do service discovery.
What I found already:
Use VCAP_APPLICATION env variable and create my own service discovery (or use something like Eureka) based on that. Does this give me always a valid IP:PORT? No matter what DEA my app is running it is reachable on this IP:PORT by other apps on other DEAs?
Register my backend app as a service and bind it, than use VCAP_SERVICES. I'd like to do this but only found documentation about registering services outside CF. Is there a simple way to bind my own app as a service?
So what would be really nice is to be able to mark an app as private but still assign a host and domain to it, so (only) my other apps could call it though CF load balancers but it would be protected from the public.
Answers inline...
As I see I have to options at deployment: with and without route.
This depends on the Cloud Foundry installation and how it's configured. On PWS, you cannot talk directly between application instances. It's a security restriction. You have to go through the router.
With route my services becomes public which is ok for my public site and my public REST API, but I don't want it for my backend services.
The best you can do here is to add application level (or container level, if you prefer) security to prevent unauthorized access.
If you don't want to do password based authentication, you could do IP based filtering. On PWS, we just added a service with Statica. You can use that to send your outbound traffic through a proxy which will assign a static IP to that traffic. You could then restrict access to your app to only the Statica IPs.
Without route I don't see how should I do service discovery.
If you remove the route, you can't sent traffic to the app.
Use VCAP_APPLICATION env variable and create my own service discovery (or use something like Eureka) based on that. Does this give me always a valid IP:PORT? No matter what DEA my app is running it is reachable on this IP:PORT by other apps on other DEAs?
You'd probably need to use this enhancement. It was added to support this type of deployment. However this will only work on Cloud Foundry installation where the networking restrictions between application instances have been relaxed. Normally you cannot talk directly between instances.
Register my backend app as a service and bind it, than use VCAP_SERVICES. I'd like to do this but only found documentation about registering services outside CF. Is there a simple way to bind my own app as a service?
You can create a "user provided" service. Look at the cf cups command. It lets you create a service with an arbitrary set of parameters and data. This could contain the URLs for your services. Once you create the service, you can bind it to any number of apps.