Zero Trust is not a product. It is a design constraint: no request is trusted because it came from a familiar network. Every request must carry identity, context and least-privilege authorization.
On Google Cloud, the practical implementation usually starts with access to internal applications and expands toward workload identity, data perimeters and edge protection.
The target architecture
The target state is simple to describe:
- users reach internal apps through Cloud IAP instead of a VPN
- CI/CD uses Workload Identity Federation instead of service account keys
- sensitive data services sit inside VPC Service Controls
- public entry points are protected by Cloud Armor
- audit logs and detections are treated as part of the architecture
| Layer | GCP capability | Purpose |
|---|---|---|
| User access | Cloud IAP, BeyondCorp Enterprise | Verify identity and context per request |
| Workload access | Workload Identity Federation | Remove long-lived deployment secrets |
| Data boundary | VPC Service Controls | Reduce data exfiltration paths |
| Edge | Cloud Armor | Filter abuse before it reaches workloads |
| Detection | Cloud Logging, Chronicle/SIEM | Find policy drift and suspicious behavior |
Replace VPN access with Cloud IAP
VPNs make network location feel like trust. Cloud IAP changes the model: identity and access conditions sit in front of the application.
For internal Cloud Run services, put the service behind a load balancer and require IAP. Then grant access to groups, not individuals. Context-aware access can add device posture, IP range or location checks when the risk profile requires it.
Remove service account keys from delivery
The second move is to remove deployment keys from CI/CD. Workload Identity Federation lets GitHub Actions, GitLab or another CI provider exchange a short-lived token for a Google service account identity.
permissions:
contents: read
id-token: write
steps:
- uses: google-github-actions/auth@v2
with:
workload_identity_provider: projects/123/locations/global/workloadIdentityPools/ci/providers/github
service_account: deployer@project.iam.gserviceaccount.com
Put sensitive services inside a data perimeter
VPC Service Controls can protect services such as BigQuery and Cloud Storage from exfiltration paths that IAM alone does not cover. Start with dry-run mode. A perimeter that blocks legitimate delivery will be bypassed politically, even if it is technically correct.
Add Cloud Armor at the edge
Cloud Armor is not a Zero Trust system by itself, but it is useful at the public boundary. Use managed WAF rules, rate limiting and explicit allow/deny policies for known integration patterns.
Migration sequence
| Phase | Scope | Success condition |
|---|---|---|
| 1 | Internal tools behind IAP | Users no longer need VPN for app access |
| 2 | CI/CD federation | No deployment service account keys remain |
| 3 | Data perimeter dry run | Violations are visible before enforcement |
| 4 | Enforcement and detection | Alerts route to an owner with a runbook |
What to avoid
Do not attempt a full enterprise-wide Zero Trust migration in one release. Start with one internal app, one CI/CD pipeline and one sensitive data service. Each slice proves a repeatable pattern.
Final check
A strong Zero Trust design should make access decisions explicit. The question is no longer "are you on the network?" It becomes: who are you, what are you using, what are you trying to reach, and should this request be allowed right now?