Private Service Connect (PSC) and Private Google Access

Private Access in Google Cloud

In a security-first environment, you want to avoid routing traffic over the public internet whenever possible. Google Cloud provides several "Private Access" technologies to keep traffic within the Google network.

For a Professional Cloud Security Engineer (PSE), the choice between Private Service Connect (PSC) and Private Google Access (PGA) depends on the source of the traffic and the type of service being accessed.

白話文解釋（Plain English Explanation）

Analogy 1: PSC Endpoint as a Hotel Room Phone Extension

Imagine your VPC is a hotel and you want to call room service (a Google API or a partner's service). Instead of dialling the public phone number (the internet), the hotel installs an in-room extension that maps x1234 directly to the kitchen via the hotel's internal PBX. A PSC endpoint is that extension: a local IP (e.g. 10.0.1.50) in your subnet that quietly forwards traffic to storage.googleapis.com or to a producer's Service Attachment, never touching the public lobby. Even if another hotel uses the same room number 1234, your extension still works because the mapping is local — that's why PSC tolerates overlapping 10.0.0.0/16 ranges where VPC Peering would fail.

Analogy 2: PGA on-prem as a Diplomatic Pouch over a Private Tunnel

Your on-premises datacentre is an embassy that needs to send files to Google's vault (GCS). The public internet is the city's open mail. Instead, you dig a diplomatic tunnel (Cloud VPN or Interconnect) and stamp every envelope addressed to *.googleapis.com with a special destination — 199.36.153.8/30 for restricted.googleapis.com (with VPC-SC protection) or 199.36.153.4/30 for private.googleapis.com (broader API set). Your on-prem DNS rewrites the address label, BGP advertises the /30 over the tunnel, and Google's edge accepts the pouch only because it arrived via your private route. No customs (public internet) involved.

Analogy 3: Service Attachment as a Restaurant's Takeout Window

A producer team runs a private SQL service behind an Internal Load Balancer. They open a takeout window — a Service Attachment — facing a dedicated PSC NAT subnet. Consumers (other VPCs, even other orgs) park a PSC endpoint at the window. The producer maintains an accept/reject list (by project ID or folder ID) like a guest list, and the NAT subnet hides the producer's real backend IPs from the consumer (the kitchen stays invisible). This is why PSC scales across organizations without IP collisions or full-mesh peering — every consumer just walks up to the window with their own internal IP.

Consuming Services via PSC Endpoints

Private Service Connect (PSC) allows you to access Google APIs or services published by other VPCs (like a third-party SaaS) using an internal IP address in your own VPC.

Key Benefits:

• Internal IP: You map a service to an IP address from your local subnet (e.g., 10.0.1.50).
• No Peering Required: Unlike VPC Peering, PSC does not require non-overlapping IP ranges and doesn't introduce routing complexity.
• Security Scoping: You can apply firewall rules to the PSC endpoint just like any other internal resource.

Private Google Access for On-Prem (Hybrid)

Private Google Access allows VMs or on-premises systems with only internal IP addresses to reach Google APIs (like GCS or BigQuery).

Two Main Flavors:

1. PGA for VPC: VMs in a VPC subnet can reach APIs if "Private Google Access" is enabled on the subnet.
2. PGA for On-Premises (Hybrid): On-premises hosts reach Google APIs over VPN/Interconnect. This requires:
   • Routing 199.36.153.8/30 (restricted.googleapis.com) or 199.36.153.4/30 (private.googleapis.com) to Google.
   • DNS overrides to point *.googleapis.com to these IPs.

Publishing Internal Services with PSC

You can also use PSC to provide your own services to other teams or organizations securely.

1. Service Attachment: Created in the producer VPC, pointing to an Internal Load Balancer (ILB).
2. Consumer Endpoint: Created in the consumer VPC, pointing to the Service Attachment.
3. PSC Interface: A newer feature that allows a producer to inject a network interface directly into a consumer VPC.

Securing PSC Connections with IAM and Firewalls

Security is applied at both ends of the PSC connection.

• Consumer Side: Use VPC Firewall rules to control which VMs can talk to the PSC endpoint IP.
• Producer Side: Use PSC Accept/Reject lists (based on project IDs or folder IDs) to control who can connect to your service.
• IAM: The compute.serviceAttachments.get and compute.endpoints.create permissions are required.

DNS Configuration for Private Service Access

For PSC and PGA to work seamlessly, DNS must resolve service names (like storage.googleapis.com) to the private IP address.

• Cloud DNS Private Zones: Create a zone for googleapis.com and add CNAME/A records.
• Service Directory: Automatically manages DNS and metadata for PSC services, allowing for easy discovery.

PSC for Google APIs (Bundled vs. Single)

• Bundled (All APIs): One PSC endpoint maps to all supported Google APIs.
• Single (Specific API): You create a specific PSC endpoint for just one service (e.g., just BigQuery). This allows for tighter firewall control.

Monitoring PSC Traffic

PSC traffic is visible in VPC Flow Logs.

• Look for the internal IP of the PSC endpoint.
• Flow logs will show the byte count and packet count, helping you audit usage and detect anomalies.

Shared VPC Integration for PSC

In a Shared VPC, PSC endpoints are typically created in the Service Project but use an IP address from a subnet in the Host Project.

• The Service Project admin needs the compute.networkUser role on the host subnet.

Comparing PSC with VPC Peering

PSE Exam Scenarios

Scenario 1: Hybrid Access to GCS

"An on-premises application needs to upload logs to a GCS bucket without using the public internet. The company uses a Dedicated Interconnect. How should this be configured?" Answer: Enable Private Google Access for on-premises hosts. Configure on-premises DNS to resolve storage.googleapis.com to the restricted.googleapis.com IP range (199.36.153.8/30). Advertise this range via BGP over the Interconnect.

Scenario 2: Connecting Overlapping VPCs

"Company A acquired Company B. Both use the 10.0.0.0/16 range. Company A needs to access a specific SQL database in Company B's VPC. What is the best solution?" Answer: Use Private Service Connect. In Company B, create an Internal Load Balancer for the SQL DB and a Service Attachment. In Company A, create a PSC Endpoint using a local IP.

Summary Checklist

• Differentiate between PSC and PGA.
• Explain the role of restricted.googleapis.com.
• List the steps to publish a service via PSC.
• Understand how DNS enables private access.
• Compare PSC and VPC Peering for cross-VPC connectivity.