Secure Service-to-Service Communication in Google Cloud

Private connectivity for serverless and managed services keeps traffic on internal network paths so serverless workloads and Virtual Private Cloud (VPC)-hosted resources communicate over private IPv4 addresses without exposure to the public internet. Direct VPC egress (opens in a new tab) provides a direct path from serverless environments into a VPC network, while Private Service Connect (PSC) (opens in a new tab) exposes a managed service or VPC-hosted service to a consumer through a private endpoint or load balancer. Together they keep service-to-service traffic on private paths with controlled access and no external IP addresses on the workloads.

1.1Direct VPC Egress from Serverless Environments

Direct VPC egress is a serverless networking option that lets Cloud Run, App Engine standard environment, and Cloud Run functions send packets directly to the internal IPv4 addresses of resources in a VPC network without setting up a connector. Traffic flows from the serverless environment directly into the selected VPC network, and from there it can also reach other networks connected to that VPC network. Because no additional connector resource is created or managed, this path reduces operational overhead when direct egress is available for the workload.

1.2Serverless VPC Access Connectors

A Serverless VPC Access connector is a resource that handles traffic between a serverless environment and a VPC network when Direct VPC egress is not an option. The connector is created in a Google Cloud project and attached to a specific VPC network and region, and then serverless services are configured to use that connector for outbound network traffic. Traffic sent through the connector into the VPC network originates from the subnet or CIDR range specified for the connector, so VPC firewall rules and routing see a predictable internal source.

Serverless VPC Access connectors are supported in every region that supports Cloud Run, Cloud Run functions, or the App Engine standard environment. Like Direct VPC egress, a connector also supports sending packets to other networks connected to the selected VPC network. The two options differ mainly in setup and in how traffic appears when it enters the VPC:

Choose Direct VPC egress when the goal is private serverless-to-VPC communication without managing a connector. Choose a Serverless VPC Access connector when Direct VPC egress is not an option and a dedicated, subnet-based source range is needed for routing and firewall control.

1.3Private Service Connect for VPC-Hosted and Managed Services

Private Service Connect (PSC) is a service-networking model that makes a workload accessible across VPC networks through a single private endpoint while exposing only the service, not the entire producer network. In this producer-consumer model, traffic flows from resources in the consumer VPC network to a PSC endpoint or consumer-managed load balancer, and then over the PSC connection to the producer service attachment and backend service. A consumer VPC can use a private IP address to connect to a Google API or to a service in another VPC network without assigning external IP addresses to Google Cloud resources.

PSC supports two consumer patterns for published services. A PSC endpoint connects directly to services published for PSC producers, while a PSC backend connects through a consumer-managed load balancer to those same published services. At Layer 4, the producer creates one or more PSC-specific NAT subnets, and PSC performs source network address translation (NAT) using an IP address selected from those subnets to route requests to the producer, which allows overlapping IP addresses between consumers and producers. At Layer 7, a PSC backend uses an internal Application Load Balancer with a URL map to choose which services are available. PSC can be extended to an on-premises network over hybrid connectivity to reach endpoints for Google APIs or managed services in another VPC network, and an endpoint can be made accessible from other regions with PSC global access, with inter-regional outbound charges for traffic destined to globally accessed endpoints.

Access through PSC is controlled at the network boundary with VPC firewall rules or firewall policies applied around the PSC endpoint. For example, outbound firewall rules in the consumer VPC can restrict which virtual machine (VM) instances can reach the IP address or subnet of the endpoints. This control is important in gated designs where the goal is to avoid connecting an entire VPC network directly to an external environment for security or compliance reasons.

Cloud Service Mesh (opens in a new tab) is a Google Cloud service that secures communication between microservices without requiring changes to application code. Each service in the mesh gets its own identity, and the data plane handles authentication, encryption, and authorization on behalf of the applications. This approach lets teams enforce consistent security across Envoy sidecar and proxyless gRPC workloads running on Google Kubernetes Engine (GKE).

2.1Zero-Trust Identity-Based Communication in the Mesh

Zero-trust communication in Cloud Service Mesh means no network traffic is automatically trusted, whether it originates inside or outside the network. Every service call that was once an in-process call in a monolithic application now travels over the network, so each call must be authenticated, encrypted, and authorized. Cloud Service Mesh provides service context-aware and request context-aware security that is independent of the underlying network, which replaces fragile IP-based micro-segmentation. The service mesh design pattern moves this complexity from business logic into the data plane, where Envoy sidecars or proxyless gRPC libraries apply declarative policies consistently.

2.2Mutual TLS for Authentication and Encryption

Mutual TLS (mTLS) is the mechanism Cloud Service Mesh uses to provide both peer authentication and encryption in transit between services. With simple Transport Layer Security (TLS), only the server presents a certificate so the client can validate the server and encrypt the session. With mTLS, both the client and the server present certificates to each other, so each workload verifies the identity of the other before encrypted data flows between them.

In Cloud Service Mesh, auto mTLS is enabled by default. A client sidecar proxy automatically detects whether the destination workload has a sidecar, sends mTLS traffic to workloads with sidecars, and sends plain-text traffic to workloads without sidecars. Services in this default mode accept both plain-text and mTLS traffic, so administrators should migrate services to only accept mTLS traffic to defend against manipulator-in-the-middle attacks.

2.3Client TLS Policies and Server TLS Policies

Client TLS policies and server TLS policies in Cloud Service Mesh control whether services must prove their identities and use encrypted channels. A client TLS policy governs how the calling workload initiates a secure session, including whether it presents its own certificate and validates the server certificate. A server TLS policy governs what the receiving workload requires, including whether it demands a client certificate and encrypted communication. Together, the policies let services assert their identities, validate peer identities, and encrypt sessions with TLS or mTLS, while plain HTTP, HTTP/2, or gRPC traffic without TLS remains vulnerable to interception and manipulation.

2.4Fine-Grained Authorization Policies

Authorization policies in Cloud Service Mesh control whether one service is permitted to access another service and which actions are allowed. Authorization decisions are based on characteristics of the client, such as its mTLS service identity or Kubernetes namespace, and characteristics of the request, such as claims or other attributes. This identity-based control allows only authorized clients to reach services with sensitive data regardless of the client network location or application-level credentials. Because mTLS certificates are bound to the TLS channel rather than passed as bearer tokens like JSON Web Tokens (JWT), an attacker cannot impersonate another workload by replaying a stolen token without access to the private keys.

2.5Certificates and Lifecycle Management

Certificates for Cloud Service Mesh workloads are issued by a managed private certificate authority, primarily Certificate Authority Service (CA Service). The GKE mesh certificates feature works with Cloud Service Mesh to automatically deploy certificates to workloads, which requires modifying Pods so workloads can receive and use mTLS credentials. Configuration flows from the Cloud Service Mesh control plane to proxyless gRPC libraries or Envoy sidecars, while certificates and keys flow from a CA Service pool to those same data-plane components. Cloud Service Mesh service security with this model is currently available only for GKE-based workloads.

The managed approach simplifies operations by automating the certificate lifecycle and integrating with Google Cloud services:

• Automatic provisioning of keys and certificates to all services in the mesh
• Automatic rotation of keys and certificates for stronger security
• Integration with GKE features such as deployment descriptors and labels
• High availability of Cloud Service Mesh and CA Service managed pools
• Authorization tied to Google Identity and Access Management (IAM) service accounts
• Interoperability between Envoy-based and proxyless gRPC workloads in either direction

These capabilities mean operators do not manually issue or renew workload certificates, and identity stays consistent as workloads scale or restart.

2.6Observability and Defense in Depth

Observability in Cloud Service Mesh captures who accessed what, using the authenticated service identity rather than only the network address. Access logging records the client mTLS identity in addition to the IP address, so operators can identify which clients accessed a service with sensitive data. This telemetry supports monitoring of policy configuration, detection of insider threats, and reduction of data-breach risk within the production network. Combined with strict mTLS, managed certificates, and authorization policies, observability provides a defense-in-depth posture where encryption, identity, access control, and auditing reinforce each other across cluster, workload, and mesh-edge layers.

Zero-trust networking with Kubernetes Network Policies is the practice of denying all pod-to-pod traffic by default and allowing only explicitly verified connections in Google Kubernetes Engine (GKE) (opens in a new tab). By default, all Pods in a GKE cluster can communicate freely with each other, which violates zero trust because it relies on implicit trust inside the cluster perimeter. A NetworkPolicy removes that implicit trust by acting as a Pod-level firewall that enforces least-privilege ingress and egress rules.

3.1Zero-Trust Model for Pod-to-Pod Traffic

The zero-trust model for pod-to-pod traffic shifts security from perimeter-based protection to verification of every access request, regardless of its origin inside or outside the network. Zero-trust networking in GKE applies this model to east-west traffic, which is traffic flowing between Pods and services inside the cluster. The model emphasizes four practices:

• Eliminating implicit trust for any user, device, or Pod
• Applying the principle of least privilege to access control
• Enforcing explicit validation of all access requests
• Adopting an assume-breach mindset for continuous verification

In GKE, every Pod must prove it is an allowed source before traffic flows from that source Pod to a destination Pod. This limits the blast radius if one Pod is compromised because the attacker cannot move laterally to other Pods without an explicit allow rule.

3.2How Kubernetes NetworkPolicy Works

A NetworkPolicy is a Kubernetes resource that controls ingress traffic flowing into selected Pods and egress traffic flowing out of selected Pods. The policy uses a podSelector to choose which destination Pods the policy applies to, and it uses policyTypes to declare whether the policy controls Ingress, Egress, or both. Allowed sources and destinations are defined by a combination of Pod labels, namespace labels, IP address ranges, and TCP or UDP port numbers.

When the first NetworkPolicy is created in a namespace, all traffic of the specified type that is not explicitly allowed by a policy is denied. Enforcement of these rules is built directly into GKE Dataplane V2, or it is handled by the cluster Container Network Interface (CNI) plugin, such as Calico. Because enforcement happens at the Pod level, the policy follows the Pods even as Pods are rescheduled across nodes.

3.3Label-Based Ingress and Egress Example

A label-based NetworkPolicy selects both the protected Pods and the allowed peer Pods by their Kubernetes labels. For example, a policy named backend-policy can select all Pods with the label app: backend and allow ingress only from Pods with the label app: frontend on TCP port 6379. In this flow, traffic flows from the frontend Pods to the backend Pods only when the source label matches app: frontend and the destination port is TCP 6379.

Any other source, such as a Pod with a different label or an external IP address, is denied because it does not match the from rule. Any other destination port is also denied because it does not match the ports rule. The same pattern applies to egress, where traffic flows from the selected Pods outward only to the destinations and ports named in the to and ports rules.

3.4Namespaces and Default Isolation

A Kubernetes namespace provides logical scope for Pods, services, and deployments so teams do not see each other's resources, but namespaces alone do not block network traffic between namespaces. Traffic still flows freely between Pods in different namespaces unless a NetworkPolicy restricts it. Network policies therefore provide the actual network segmentation that namespaces alone cannot enforce.

By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from Pods in that namespace. To implement zero trust, create a default isolation policy that selects all Pods but allows no ingress traffic, then add narrower allow policies for each required flow. A common pattern is to place sensitive workloads in a separate namespace and define policies that make those Pods inaccessible from other namespaces except for specific labeled sources.

3.5Defense in Depth with VPC Firewall Rules

Defense in depth in GKE combines Virtual Private Cloud (VPC) firewall rules at the node boundary with NetworkPolicy at the Pod boundary. VPC firewall rules and Network Policies work together, but they operate at different layers and protect different resources.

Use VPC firewall rules to limit external north-south access to nodes, and use NetworkPolicy to limit internal east-west access between Pods. Do not replace Pod-level rules with node-level egress-deny firewall rules, because applying egress-deny rules to nodes can break cluster features such as NodePort and kubectl exec. For Layer 7 controls such as authorization, throttling, and metrics, combine NetworkPolicy for Layer 4 Pod traffic with a service mesh such as Istio for Layer 7 endpoint traffic.

Private connectivity, Cloud Service Mesh, and Kubernetes Network Policies provide three complementary layers for secure service-to-service communication. Direct VPC egress and Private Service Connect keep traffic on private paths between serverless workloads, VPC resources, and managed services without public exposure. Cloud Service Mesh then authenticates and encrypts that traffic with identity-based mTLS and authorization, while Kubernetes Network Policies restrict which Pods can send or receive traffic at all. Together they enforce least privilege at the network edge, the Pod boundary, and the service-identity layer.

Key Facts

• Direct VPC egress lets Cloud Run, App Engine standard environment, and Cloud Run functions send packets directly to internal IPv4 addresses in a VPC network without a connector.
• Private Service Connect exposes a producer service to a consumer VPC through a private endpoint or load balancer without exposing the entire producer network and without external IP addresses.
• Cloud Service Mesh uses mutual TLS (mTLS) so client and server workloads verify each other with certificates and encrypt all TCP communication, with auto mTLS enabled by default.
• A Kubernetes NetworkPolicy uses podSelector and policyTypes to control ingress and egress for selected Pods, and creating the first policy in a namespace denies all traffic of that type that is not explicitly allowed.
• Virtual Private Cloud (VPC) firewall rules protect GKE cluster nodes at Layer 3 or Layer 4, while Kubernetes NetworkPolicy protects applications at the Pod level.