Accessing Azure VNet from Azure Logic App - azure-logic-apps

I have a Logic App and, in my workflow, I need to call a service that is deployed in a vnet. So far my research points me to using API Management to talk to the VNet resource, or to reimplement my workflow as an Azure Function.
Since the resources, blog posts, etc, I am finding are several months-old, I thought I asked you here. Are these indeed the options I have?

Asumming that:
Your VNET is locked down
Your service is an HTTP service (either RESTful or SOAP)
the VNET doesn't allow HTTP calls from outside.
Then you have a couple of options:
Use On-Premises Data Gateway. The OPDG is an agent that you can deploy on a VM in your VNET and would allow you to call HTTP endpoints. You need to create a Custom Connector which uses the OPDG. This is in preview, and unfortunately the documentation is not there yet, but I've implemented it. OPDG has no cost, you pay just for the VM and traffic.
Deploy your APIM within the VNET and deploy App Gateway on top which will allow access from outside the VNET. This requires more work (networking) and you will need to pay more.
Deploy APIM outside the VNET, get your own static IP, and only allow HTTPS traffic from your APIM to your VNET. Some people might not like this option, but you can consider it.
HTH

Related

Is there a way to limit only allow incoming requests from other App Engine services?

I have four services running within the same app on App Engine. I have a frontend SvelteKit application, and three backend services. If possible, I'd like to set up security in such a way that the backend services will only accept HTTP requests from the frontend application (which sends all API requests via its Node server).
Is there a way of doing this without spending a load of money on a Serverless VPC Access connector?
Ideally I want to keep these all within the same GCP project as well. So far the only solution I can come up with is to ship the services with a secret that they check against when receiving a request, but there must be a better way to do it.
Take a look at Identity Aware Proxy
Pay attention to the part of the above documentation that says
In order to make a resource publicly-accessible (while sibling resources are restricted), grant the IAP-secured Web App User role to allUsers or allAuthenticatedUsers.
Per your use case, your front-end application will be available to the public while your 3 backend services will only be available to the front-end application
Since your backend services are now secured (via IAP), you have to programmatically invoke them in your front end. See documentation on how to do that.

Creating an API proxy for an Azure Static Web App

I have a static website (React SPA) hosted as an Azure Static Web Application, I also have a flask backend that is hosted online, is there a way for me to add the URL of the backend so that all requests will go there? (Similar to adding a proxy to package.json in React)
According to your problem description, my understanding is that your backend program has been hosted online.
Now you want to allow Azure Static Web App to access this service. Suppose this service has an interface /MyTestController/TestConnection. You want the webapp program to pass, similar to http(s)://yourdomain.com/MyTestController/TestConnection or 167.2**.255.*2:8080/ MyTestController/TestConnection to access this interface, right?
Please use the following methods to troubleshoot and test.
Step 1.
Check the public network address on your backend server, because you are not sure where you are deployed, whether it is a LAN host or a third-party network service provider. You can check whether the host address where your service is located is on the public network or on the internal network.
If you are deploying on your own PC or LAN host, and get the intranet address, then this service cannot be accessed.
If you are deploying on a third-party cloud server or web service, you can open the specified port or service by setting relevant settings in the third-party server.
The specific details need to tell me how you deploy your backend program to better help you.
Step 2.
The simplest way to deal with it is to create a python webapp program in the Azure service and deploy your back-end service.
Of course, it is recommended that you troubleshoot the problem first. At present, your backend service public network should not be accessible, so you want to use proxy to handle it. Specific problems are analyzed in detail.
If you have not deployed the service to a third party, just deploy it on your own PC and other LAN hosts. As a test, you can use tools such as oray to try.

Can a private on-premise network access GAE Flex via Cloud VPN?

I was wondering if a site-to-site VPN setup like the one in this diagram is possible:
From the diagram, I could access the GAE Flex instance's internal IP that are launched in the VPC from the on-premise server, but I don't think I could invoke a *.appspot.com URL without needing to go outside of the tunnel, correct?
The on-premise network can only whitelist IP ranges for external HTTPS access but it seems like GAE can't support such a configuration?
Is this kind of setup only possible by setting up a GCE reverse proxy? If that's the case, would I just be better off deploying my application as a Kubernetes cluster?
So I did an experiment that revealed several things about this setup in case any is interested in this in the future:
In the above diagram, under the assumption that the on-premise instances are in a private subnet with no external IP, they can reach app engine instances via their internal IP.
Just because they can reach the App Engine flexible instances via their internal IP, this doesn't mean that they can then be port forwarded to invoke your function.
The only real use case for App Engine flex working with Cloud VPN is if you need the App Engine instances to be able to reach either your private cloud and/or on-premise instances i.e. going from right to left in the above diagram.

Is there a way to deploy internal facing applications in Google App Engine?

Is there a way to deploy "internal facing" applications in Google App Engine. AWS offers this capability as explained here and so does Azure as explained here.
What is the GCP equivalent for this? It appears App Engine Flexible Environment could be the answer but I could not find a clear documentation on whether Flexible Environment is indeed the way to host intranet facing applications. Is there someone from GCP who can advise?
Update
I tested the solution recommended by Dan recently. Listed below are my observations:
App Engine Flex allows deploying to a VPC and this allows VPN scenarios. The VPN scenarios however is for connections (originating) from App Engine to GCP VPCs or to other networks outside GCP which can be on-prem or in another cloud.
Access (destined) to the app itself from a GCP or another network is always routed via the internet facing Public IPs. There is no option to access the app at a private IP at the moment.
If there's another update, I will update it here.
Update 28Oct2021
Google has now launched Serverless Network Endpoint Group(NEG)s. With this users can connect AppEngine, Cloud Run & Cloud Function endpoints to a LoadBalancer. However at the moment, you can only use Serverless NEGs with an external HTTP(S) load balancer. You cannot use serverless NEGs with regional external HTTP(S) load balancers or with any other load balancer types. Google documentation for Serverless NEGs is available here.
I'm not sure this meets your requirements, but it's possible to set up an App Engine Standard application (not certain about Flexible) such that it is only accessible to users logged into your G-Suite domain. This is the approach I've used for internal-facing applications in the past, but it only applies if your case involves an entity using G-Suite.
You can set this up under the App Engine application Settings, under Identity Aware Proxy.
In this scenario the application is still operating at a publicly accessible location, but only users logged into your G-Suite domain can access it.
It should be possible with the GAE flexible environment. From Advanced network configuration:
You can segment your Compute Engine network into subnetworks. This
allows you to enable VPN scenarios, such as accessing databases within
your corporate network.
To enable subnetworks for your App Engine application:
Create a custom subnet network.
Add the network name and subnetwork name to your app.yaml file, as specified above.
To establish a VPN, create a gateway and a tunnel for a custom subnet network.
The standard env GAE doesn't offer access to the networking layer to achieve such goal.

Expose Services to local environment for production

I am planning to move different service to Swisscom Application Cloud, but I have a problem on database access.
My setup is a web application and a local service sharing the same database, unfortunately the local service can't be moved to the cloud at the moment, there is a way for my local service to access the database in the cloud?
I think using the service connector in production is not a good idea
I know the best solution would be to avoid direct access to the database from the local service and expose REST API from the web application but that's out of budget
You are right: External service access to database services running in the cloud is not possible and the service connector is not suitable for permanent use.
This is by design: The services in the marketplace are meant to be used by the apps running there - the apps themselves should expose their functionality over HTTPS preferably. We'd like to avoid allowing external access to the databases; this would open the door for a lot of external (legacy) apps with a complete different set of requirements.
So the solution that fits the architecture best is indeed your suggestion: Expose the data needed for the legacy service as part of the apps' Web API.
Since that is out of question, it might make sense to host the database outside of the cloud (i.e. where the local service runs or on some 3rd party provider) and connect your app in the cloud to this externally running database.

Resources