I am trying to connect to a cloud function with HTTP trigger. It has an ingress rule to allow only internal traffic, I want to access this from another function running in a different project.
I tried creating VPCs in both the projects and have also peered them. In the cloud functions I am using a vpc connector in the egress but I still am not able to access.
Is there a direct way to access a cloud function running in say project-A from a cloud function running in say project-B using the network setting?
P.S Due to some constraints I cannot use shared VPC.
You can't achieve this today. Indeed, when you perform a VPC Peering, you define a special hop in the routes to go to the other VPC.
The problem is: When you call your Cloud Function, you don't call it by its IP but by its DNS.
Thereby, you won't use your VPC peering to reach the right VPC and, through it, the cloud function. You will use the public DNS, as any external system can do this, and thus you are blocked.
Related
I am developing a solution where a Java application hosted on GKE wants to make an outbound HTTP call to a cloud function which is deployed under a different GCP project, where the GKE operates on a shared network of which possesses firewall rules for the CIDR ranges in that shared network.
For example - GKE cluster & Application deployed under GCP Project A, wishes to invoke a Serverless GCP Function deployed to project B.
There are a number of firewall rules configured on the shared network of which the GKE is operating upon, causing my HTTP call to time out, as the HTTP trigger URL is not mapped to an allowed CIDR range (in that shared network).
What have I tried?
I have lightly investigated one or two solutions which make use of Cloud NAT & Router to proxy the HTTP call to the Cloud Function trigger endpoint, but I am wondering if there are any other, simpler suggestions? The address range for cloud functions is massive so allowing that range is out of the question.
I was thinking about maybe deploying the cloud function into the same VPC & applying ingress restrictions to it, would that allow the HTTP trigger to exist in the allowed IP range?
Thanks in advance
Serverless VPC Access is a GCP solution specially designed to achieve what you want. The communication between the serverless environment and the VPC is done through an internal IP address, and therefore never exposed to the Internet.
For your specific infrastructure, you would need to follow the guide Connecting to a Shared VPC network.
I have one VPC Serverless connector which helps Cloud Functions to access the default VPC and then transit to another peered VPC from another project.
The setup was working fine until yesterday.
No change happened.
Now my functions are timing out because the call to internal IPs do not return anything.
I activated the Flow logs for the VPC subnet on which the cloud functions are deployed (us-central1) and they do not show any activity at all, which points me at the Serverless VPC connector.
However it does not have any option to enable log.
I cannot try the network intelligence connectivity test since serverless infra has no IP.
I tried creating another VPC Connector with a different internal IP range, still no flow.
Any idea how I could debug this?
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 need to set up a connection between VPCs. My plan was VPC peering but customer asks for Private Link as they heard it is the secure way. But I am mostly concerned with performance overhead with the private link. What I understood (maybe wrong); in the Private Link architecture there is an extra NLB. Does not this introduce a latency because of extra network hop?
VPC peering and Private Link serve two different purposes.
VPC peering enables you to connect two VPC in a same way you would connect to local networks together, and remote networks using VPN. VPC peering allows network traffic from one VPC to the second VPC. For example, you can SSH from an instance in VPC A into an instance in VPC B.
Private Link is used to expose individual services of yours in VPC A to VPC B. But this does not allow for free flow of network traffic from VPC A to VPC B. For example, let's say you've developed very cool application for image segmentation. The application and all its databases and other resources that it requires are in VPC A. Now a friend comes and he/she would like to use your application. But the friend is in VPC B. Since your application is private, not exposed to the internet, a way for your friend to use the app would be to expose it through Private Link. For this you create NLB in-front of your application, and your friend will get network interface in his VPC B through which he can access your private application in VPC A.
Based on this and your question, there is no clear answer as the two options are used for different purposes. I would suggest to clarify exactly what are your or your customer requirements.
But generally, both will be equally fast. AWS docs write about VPC peering the following:
AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.
Other examples from AWS docs is here:
Example: Services Using AWS PrivateLink and VPC Peering
Edit: Based on #Michael comment.
I am looking to find a way to communicate between 2 VPCs in AWS without the use of VPN connections to and from a certain company (outside AWS) - so that the traffic does not pass through the company's gateway. Or, simply said, access an EC2 instance in a VPC from another VPC (both in AWS) without leaving the Amazon Network (not going out on the internet, not even encrypted).
Basically what I want to do is to have a VPC acting as a "proxy" (let's call it PROX) and one acting as a "target" (called TARG). Now I want to connect a company through VPC to the PROX and inside the PROX route the requests to the TARG. Is this achievable? I would go for a traditional public-private single VPC, but I was asked to look into the previously described "architecture".
Use two Linux machines as VPN GW, each in each VPC.
Configure IPsec VPN between them.
That's all you need
This is not possible. You have to use a VPN connection between the two VPCs. You can directly connect them though relatively easily using the pair of IPSec gateways though. This is the recommended method of cross-connecting VPC's across regions.