Serverless computing is becoming mainstream of ad hoc computing in Cloud environments. In GCP, Cloud Function, Cloud Run, and AppEngine are popular among developers. All those serverless APIs used to be only able to communicate with other Google APIs until Google released Serverless VPC Access about 2 years ago. Now you can have your Cloud Functions and Cloud Run to connect to your VMs on your VPC, on-prem, or your peered service networks.
How does it really work? Many developers have no clue of the complexity of Google magic, and so often they run into issues when they try to set this up. Mostly they have a misunderstanding of how the Serverless VPC Access works.
What is Serverless VPC Access
GCP Serverless environments such as Cloud Run, Cloud Function and AppEngine Standard are Google managed services, running outside your VPC network. Serverless VPC Access makes it possible for you to connect Google serverless environment directly to your Virtual Private Cloud network via internal DNS and Private IPs.
Benefits:
- Requests and Responses sent to your VPC network are never exposed to the internet.
- Communication through Serverless VPC Access can have less latency compared to the internet.
- Connect to Google APIs via Private APIs or restricted APIs
Serverless VPC Access Overview
- GCP Serverless Access is using Connectors which are google managed proxy VMs running on your designated ‘/28” subnet as Managed Instance Group
- The proxy VMs running on your subnet are not visible to you, you can only see the logs
- Serverless APIs egress to VPC via those VM proxies
- VPC egress to Serverless APIs via Google private access
- Serverless Connectors can be created in service project or host project (preview)
Serverless VPC Access Configuration Considerations
- You must create /28 subnet in the host project
- The region has to be the same region as your serverless services
- But connector can connect to any region or any services your VPC could connect
- RFC1918 and RFC6598 are the only CIDR ranges serverless APIs are able to communicate to your VPC — This means you can not use other CIDRs such as RFC1112
- You can choose the instance type between 3 options and set the minimum/maximum number of instances — Minimum 2, Maximum 10
- Only three type of VMs to choice: micro, small, medium
- Each type has different supported throughput bandwidth
Serverless VPC Access Firewall Considerations
- Google managed proxy VMs
- All VMs with name “aet-*”. They not visible to you but you can see those VMs with that name convention from the logs
- All VMs have two tags
vpc-connector
vpc-connector-REGION-CONNECTOR_NAME
- Serverless VPC Connector only supports TCP, UDP, not ICMP
- Understand IP ranges from Serverless services:
- NAT ranges: 107.178.230.64/26, 35.199.224.0/19
- Understand Proxy Firewall rules needed for NAT Proxy:
Ingress/Egress allow: TCP 667, UDP 665–666, ICMP
- Managed Instance Group always needs Health Check
Health Check CIDR: 130.211.0.0/22, 35.191.0.0/16, 108.170.220.0/23
Health Check firewall: allow ingress TCP 667
- Use VPC connector tag “vpc-connector” as firewall rule only for above default firewall rules
- For specific VPC resource access use:
Service Account: service-SERVICE_PROJECT_NUMBER@gcp-sa-vpcaccess.iam.gserviceaccount.com
Tag: vpc-connector-REGION-CONNECTOR_NAME
Allow Egress from the connectors (optional if you have default egress deny)
Allowing Ingress on these VPC resources for from connectors
Serverless VPC Access in Service Project
- Host Project Admin will need to grant networkuser role on the /28 subnet to Service Project service accounts:
service-SERVICE_PROJECT_NUMBER@gcp-sa-vpcaccess.iam.gserviceaccount.com
SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com
- service-SERVICE_PROJECT_NUMBER@gcp-sa-vpcaccess.iam.gserviceaccount.com needs vpcaccess.serviceAgent role in service project
- For specific firewall rules
Service Account: service-SERVICE_PROJECT_NUMBER@gcp-sa-vpcaccess.iam.gserviceaccount.com
Tag: vpc-connector-REGION-CONNECTOR_NAME
Serverless VPC Access Configuration in Host Project (preview)
- Host Project Admin will provision Serverless VPC Connector in the host project
- Host Project Admin needs to provision following service accounts of Service Project with vpcaccess.serviceAgent role in Host Project
- Cloud Run:
service-SERVICE_PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
- Cloud Function
service-SERVICE_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
- App Engine — The person or service account that performs App Engine deployments in the service project
Serverless VPC Access in Host Project (preview) Pros vs Cons
Pros:
- Centralized Network Management
- Perverse Subnet and IP Addresses
- Lower Cost on connector consumptions
- Reduced Maintenance
Cons:
- Multiple service projects sharing serverless connectors requires unified access control
- The same VPC Firewall rules governance across all service projects
How to Create and Use Serverless VPC Access
Create Connectors
gcloud compute networks vpc-access connectors create CONNECTOR_NAME — region REGION — subnet SUBNET \
# If you are not using Shared VPC, omit the following line.
— subnet-project HOST_PROJECT_ID \
# Optional: specify minimum and maximum instance values between 2 and
10, default is 2 min, 10 max.
— min-instances MIN — max-instances MAX \
# Optional: specify machine type, default is e2-micro
— machine-type MACHINE_TYPE
Use Connectors
- Cloud Run — “gcloud run deploy” or “gcloud run service update” — vpc-connector CONNECTOR_NAME
- Cloud Functions — “gcloud functions deploy” -vpc-connector CONNECTOR_NAME
- AppEngine — Add Serverless VPC Access field in app.yaml:
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
Serverless VPC Access Org level Security Considerations
Org Policy Constraints
- Allowed ingress settings (Cloud Functions)
ALLOW_ALL/ALLOW_INTERNAL_ONLY/ALLOW_INTERNAL_AND_GCLB
ALLOW_ALL/ALLOW_INTERNAL_ONLY/ALLOW_INTERNAL_AND_GCLB
PRIVATE_RANGES_ONLY/ALL_TRAFFIC
PRIVATE_RANGES_ONLY/ALL_TRAFFIC
serverless-vpc-access-images
VPC Service Control
- vpcaccess.googleapis.com is supported by VPCSC
- AppEngine is NOT supported on VPCSC — There is no roadmap for it
- Cloud Function is supported by VPCSC
Cloud Function uses Cloud Build
Cloud Build SA needs be added to access level policy
- Cloud Run is supported by VPCSC
GCR and Artifact Registroy must be in the same VPCSC
