Blog

May 6, 2026 4 min read

Zero-Trust Networking on GCP for Financial Services

Implementing zero-trust network architecture on Google Cloud for regulated workloads. VPC Service Controls, BeyondCorp, and workload identity patterns from production.

The perimeter security model that banks have relied on for decades — firewall the data centre, trust everything inside — does not work in the cloud. When your trading systems run on GCP, your OMS in a Kubernetes pod needs to authenticate to a market data API without relying on a network boundary.

We have implemented zero-trust networking on GCP for tier-one banks and fintechs. The principles are straightforward: no implicit trust based on network location, every access request authenticated and authorised, and least-privilege access enforced at every layer.

Who Is This Guide For?

This guide is for cloud security architects, platform engineers, and infrastructure leads at financial services firms implementing zero-trust networking on GCP.

By the End of This, You’ll Know…

How to implement VPC Service Controls for data exfiltration prevention
How BeyondCorp enterprise provides context-aware access without VPNs
How workload identity federation eliminates long-lived service account keys

VPC Service Controls

VPC Service Controls create a security perimeter around Google Cloud services. They prevent data exfiltration by blocking access to GCP services from outside the perimeter, even if the caller has valid credentials.

Perimeter Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: accesscontextmanager.cnrm.cloud.google.com/v1beta1
kind: AccessContextManagerServicePerimeter
metadata:
  name: trading-perimeter
spec:
  title: Trading Production Perimeter
  perimeterType: PERIMETER_TYPE_REGULAR
  status:
    resources:
    - projects/1234567890
    accessLevels:
    - accessPolicies/123/accessLevels/corp_access
    restrictedServices:
    - storage.googleapis.com
    - bigquery.googleapis.com
    - dataflow.googleapis.com
    vpcAccessibleServices:
    - enableRestriction: true
      allowedServices:
      - compute.googleapis.com
      - container.googleapis.com

The perimeter ensures that trading data in BigQuery and Cloud Storage is accessible only from within the authorised VPC or through the BeyondCorp access proxy. Exfiltration via a compromised service account key is blocked because the perimeter rejects calls from outside the authorised network.

BeyondCorp Enterprise

BeyondCorp Enterprise provides zero-trust access to GCP services without a VPN. Users and services authenticate via identity-aware proxy (IAP), which enforces access context (device posture, user identity, geolocation) before granting access.

Access Levels

Define access levels for different classes of trading users:

Access Level	Requirements	Grants Access To
Trading desk	Corp device + MFA + Trading IP range	OMS, Market data dashboards
Risk management	Corp device + MFA + Risk team group	Risk analytics, VaR reports
External auditor	Device posture check + MFA + Time-bound	Audit log exports, read-only
Emergency break-glass	MFA + Manager approval	All systems (with audit alert)

IAP for TCP Forwarding

BeyondCorp’s IAP TCP forwarding enables SSH/RDP access to compute instances without public IP addresses or VPN bastion hosts:

1
2
gcloud compute start-iap-tunnel trading-node-1 3389 \
  --zone=europe-west1-b

The user authenticates via IAP. The tunnel is authorised based on the user’s access level. No firewall rule opens SSH to the internet.

Workload Identity Federation

The most common GCP security finding in financial services audits is long-lived service account keys stored in configuration files. Workload Identity Federation eliminates this entirely.

Instead of downloading a JSON key for a service account, you bind a workload (Kubernetes pod, Compute Engine instance, Cloud Run service) to a service account at deployment time:

1
2
3
4
5
6
7
8
9
apiVersion: v1
kind: Pod
metadata:
  name: trading-engine
  annotations:
    iam.gke.io/gcp-service-account: [email protected]
spec:
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"

The pod authenticates to GCP APIs as [email protected] without any static credentials. There is no key file to rotate, no key to leak.

Implementation Checklist

Layer	GCP Service	Controls
Network	VPC Service Controls	Data exfiltration prevention, perimeter enforcement
Access	BeyondCorp / IAP	Context-aware access, no VPN required
Auth	Workload Identity Federation	No static credentials
Logging	Cloud Audit Logs	Immutable audit trail for all API calls
Monitoring	Security Command Center	Misconfiguration detection, Vulnerability scanning

What You Can Actually Use Today

Tool	Purpose	Source
VPC Service Controls	GCP data exfiltration prevention	GCP native
IAP	Zero-trust access proxy	GCP native
Workload Identity Federation	No static credentials	GCP native

FAQ

Can I use zero-trust networking on-premise as well? Yes. BeyondCorp principles apply to on-premise environments using the same identity-aware proxy model. Google Cloud’s BeyondCorp Enterprise extends to on-premise applications via the IAP connector for on-premise deployments.

Does zero-trust networking eliminate the need for a firewall? No. Firewalls still provide a necessary layer of network segmentation. Zero-trust adds identity-aware access on top of network segmentation. Both layers are necessary for defence-in-depth.

How does zero-trust affect trading latency? IAP adds 5-15ms of latency per request due to token exchange and access policy evaluation. For trading system API calls, this is acceptable. For microsecond-level FIX gateway communication, use VPC-native connectivity without IAP.

Who Is This Guide For?#

By the End of This, You’ll Know…#

VPC Service Controls#

Perimeter Configuration#

BeyondCorp Enterprise#

Access Levels#

IAP for TCP Forwarding#

Workload Identity Federation#

Implementation Checklist#

What You Can Actually Use Today#

FAQ#

Further Reading#