Is it possible to access GCP PaaS (App Engine , Cloud Function, Cloud Run) internally (throught VPC)
I see in this doc : https://cloud.google.com/vpc/docs/configure-serverless-vpc-access
"Serverless VPC Access only allows requests to be initiated by the serverless environment. Requests initiated by a VM must use the external address of your serverless service—see Private Google Access for more information."
But searching for something like "Serverless VPC Access allows in/out requests"
You have 2 ways: in and out
Request TO serverless APP
You can use ingress control with Cloud Functions and Cloud Run services. You can say: I want that only connections from my VPC (or VPC SC perimeter) access to my serverless APP. With App Engine, you have firewall rules but doesn't work with private IP.
Request FROM serverless APP
Here you want to reach private resource exposed only on your VPC with a private IP. And with Cloud Run, Cloud Functions and App Engine, you can plug a serverless VPC connector to achieve this.
EDIT 1
With your appliance firewall deployed on Google Cloud, App Engine isn't the perfect product for this. Indeed, with App Engine you can't control the ingress traffic, and you always accept the traffic from the internet, even if you have a stuff (here your appliance) already on Google Cloud Network with a private IP.
The solution here (to test, depends on the appliance capacity) is to use Cloud NAT and to route all the traffic of the subnet on which the appliance is deployed, and to use a reserved static IP.
Then, on App Engine, you can set a firewall rule to accept only traffic from this reserved static IP.
The latency will increase with all these layers...
Related
I have an API launched on a cloud run service in project dev. I don't want to expose the API so I set it's ingress to Allow internal and Cloud load balancing traffic.
I have another cloud run frontend application in a different project. It's connected with a VPC connector to the project's VPC and routes all traffic through the VPC connector.
I want to access the same API service from the previous project so I basically created a VPC Peering between the two projects thinking that traffic to the other project's cloud run service will go through the Peering.
It seems not to be the case as my application is still not able to reach the other project's API cloud run service. The frontend service sends the traffic not directly to the cloud run url but it sends it through a server/api request (Using Next.JS API route here for context) so I was of the view that it will go through the VPC connector, through the Peering and find the other project's cloud run url.
Is there something I did wrong here or it's not a setup that's going to work at the moment.
GCP Serverless VPC access connectors and VPC Peering are not transitive by default.
Non transitivity in GCP networking basically means that if we have 3 networks, A,B and C. If network A is connected to B and B is connected to C, it does not mean that A is connected to C. Read more on GCP network peering transitivity here: vpc-peering-docs.
Cloud run does not live on the user or organization's VPC but lives in a separate network (owned by Google).
Hence when the network in project A is peered with the network in project B, the connection from the cloud run service becomes a third network and since peering is not transitive, the cloud run network can of course connect to resources in the same project through the serverless access vpc connector but cannot connect to the network in project B even though the two networks are peered.
If you still want to connect your cloud run services in a project to different project services privately, then consider reading this documentation: cloud run authentication. With this method, you can restrict traffic to require authentication using IAM credentials for example.
Credit to John Hanley
We have an app running on cloud run and it is authenticated only from API gateway.
But still cloud run has *.run.app public domain associated with it and seems like it can still be security issue for sensitive applications which deal with PII data.
How can we run the cloud run inside private VPC network so that private IP is assigned to it?
Is this a con for cloud run over GKE in terms of private VPC network?
Cloud Run cannot have a "private" IP for your service. In general, Cloud Run will be always have its own *.run.app.
Said that what you can do is to restrict the ingress of the service but you should keep in mind that if you set the service as Private or Private + Load Balancer it will be not reachable by API Gateway but by resources in the VPC.
Of course you can set an Internal Load Balancer + MIG as a proxy + Cloud Run private ingress but this increases the configuration overhead.
I think this will change in the future since there is a Feature Request to support Internal HTTPS Load balancers + Serverless NEGs and with the ingress Internal and Cloud Load Balancing you will have a "private" IP for your service (You can ask access for the preview here).
Answering your last question Is this a con for cloud run over GKE in terms of private VPC network? This is something you should evaluate according to your requirements and in general this particular question is an opinion-based which is off-topic. Consider the facts and choose what is better for you.
Is it not possible to run GCP cloud functions (or any GCP serverless compute resources for that matter) inside private networks? Are they always using shared capacity and public networks? Am I missing something? Don't confuse this with egress, I know it is possible to access private networks from serverless resources, but is it possible to limit access to the functions at the network level? AFAIK you can do this with lambdas on AWS and with app service on Azure (although on Azure it was expensive since you need to move away from shared capacity).
You have 2 way traffic in Cloud Function: ingress and egress
Ingress: you can limit the traffic coming from internet, or uniquely from project VPC or VPC SC
Egress: By default, the traffic is directly routed to internet. You can use a serverless VPC connector for:
Either routing only the private IP (RFC1918) to the VPC
Or routing all the traffic to the VPC.
I have an AWS account with an EC2 in it that I am trying to connect to a Cloud SQL Server (MySQL 5.6) inside of Google Cloud Platform.
I have successfully set up a VPN between AWS and GCP and can echo a message over nc between an ec2 on AWS and a vm on GCP.
As GCP managed DB's are not placed inside of a VPC of my choosing I followed this guide to give the DB a private IP and to then peer that with my google VPC. I tested this works by accessing the DB via pymsql from an VM in GCP using the private IP of the DB.
However my issues come from connecting the EC2 inside of AWS to the Cloud SQL DB in the same way, I have followed this guide to allow the use of the DB's private IP from an external source but I seem to be getting stuck with how to set the routing up to the peered network the DB is sitting in using AWS Routing.
The problem has been sorted!
In the Advertised routes Settings of my Cloud Router, I had misunderstood the function of Advertise all subnets visible to the Cloud Router (Default)
I needed to instead choose Create custom routes" And then the sub-option Advertise all subnets visible to the Cloud Router.
This then allowed me to add the Cloud SQL subnet to my router to that IP block propagate over to AWS.
I have a project setup where I can connect to a local resource through AppEngine Flexible instances launching on a VPC network that is setup with a Cloud VPN connection to my local firewall.
With the release of Serverless VPC for the us-east1 region, I wanted to replace my setup to use AppEngine Standard Gen2 instances vs Flexible for the cost savings. I setup a Serverless VPC for the region/network my AppEngine app is hosted on and my Cloud VPN connection is configured for, updated my app.yaml accordingly, and pushed a new version.
I keep getting timeout errors for the new version that is trying to use Serverless VPC to connect to my local resource.
Some context:
The VPC Network is named "portal" and setup to "Auto" mode (auto creation of subnets for each region)
Cloud VPN is setup as a Classic VPN in the "portal" network with Route-based routing in the us-east1 region, connecting to my remote local 192.168.11.0/24 subnet.
A route exists on the VPC network for destinations 192.168.11.0/24 to use the Cloud VPN I have setup as the next hop (automatically created)
With the above, AppEngine Flexible deployments on the "portal" network can connect to my local resource as can any other Compute Engine VM on the "portal" network
I setup the Serverless VPC connector on the us-east1 region with the subnet 10.8.0.0/28
I'm not too clear how Serverless VPC works so I'm not sure how to even begin troubleshooting. When I click on the route rule for the 192.168.11.0/24 destination, I can see the AppEngine Flexible instances listed along with some "serverless-vpc-access" tagged instances that appear to be on a different subnetwork but using 10.8.0.0/28 IPs.
Should this configuration be working? If not, what changes do I need to make in order to support this?
Your problem (most likely) is caused by static routing. Do you have a route for return traffic coming from your VPN going to the VPC connector? Look at the routes defined for the VPN.
The purpose of a Serverless VPC connector is to allow the connection from the App Engine Standard to your VPC Network since the App Engine Standard environment is hosted and managed by Google and is not part of your VPC Network.
More details can be found here: [https://cloud.google.com/vpc/docs/configure-serverless-vpc-access].
That being said, you should verify the following:
Make sure that you’ve added the new subnet (/28) to your local on premise routes, with your VPN Gateway as the next hop. Since you’re using route-based routing, there is nothing to do regarding the Traffic Selectors on the VPN.
Make sure your local firewall is configured to accept the connection back and forth with the new configuration (/28).
While this probably won't apply to you, I just wanted to point out that communication through the Serverless VPC connector to the App Engine Standard environment is not possible unless it’s done on the same original tcp connection that originated from that same App Engine (TCP Established).
Your configuration, as you described is definitely possible to achieve. As mentioned, there are only a few things you need to verify to make sure it works.