Chapter 35

Zero-Trust GCP Architecture

Scope. This chapter is a composition, not a survey. Every component it names is owned by an earlier chapter — Chapter 4 owns federation, context-aware access, and IAP; Chapter 5 owns private connectivity and segmentation; Chapter 20 owns VPC Service Controls. Nothing here re-teaches any of them. What is here is the argument for how they fit together, expressed against a published reference model, plus §35.10's material, which no other chapter owns. Prerequisites. Chapter 4 in full, Chapter 5 (§5.16–§5.19, §5.31–§5.32), Chapter 19, Chapter 20. Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; NIST SP 800-207; see sources at end.

Zero trust is easy to state and hard to check: never trust a request because of where it came from, and authorize every one of them explicitly. Stated that way it is a slogan. What makes it an architecture is a decomposition you can hold a design against, and NIST SP 800-207 supplies one.

Its core abstraction is three components. A policy engine decides whether to grant access. A policy administrator establishes or terminates the connection the engine authorized. A policy enforcement point sits in the data path and enforces that decision. Every zero-trust design is an assignment of real products to those three roles, and the useful question about any GCP architecture is which product plays each part.

The composition matters more than the components. Chapter 4's controls authenticate; Chapter 20's perimeter constrains where an authenticated credential works; Chapter 19's edge filters what arrives. Each is defeatable alone. Identity without a perimeter means a stolen credential works from anywhere; a perimeter without identity means anyone inside is trusted; an edge without either is a filter in front of an open door. The value is in the overlap.

One honest limit runs through the chapter and surfaces in §35.10. GCP authorizes at the moment of a request and issues credentials that outlive it. That gap between "authorized then" and "authorized now" is where the model is weakest, and it is the part with the fewest first-party controls.

35.1 Identity as the Perimeter §

The claim is that a request's authorization should derive from who is making it and under what conditions, not from which network it arrived on. §4.13 owns the human-versus-machine distinction and §4.14 owns Google's BeyondCorp framing.

Mapping GCP to the NIST 800-207 roles is the composition this chapter exists to state:

The important structural fact is that GCP has no single enforcement point. Access to a Cloud Storage object is enforced by the Cloud Storage API; access to a VM's SSH port is enforced by IAP; access from outside a perimeter is enforced by VPC Service Controls. A design that assumes one chokepoint will leave the others unconsidered.

Network position still means something and should mean less each year. The direction of travel is from "this subnet is trusted" to "this identity, on this device, in this context, may perform this operation on this resource" — and the intermediate states are where most estates actually live.

What makes the identity trustworthy is Chapter 4's material: federation rather than passwords (§4.3), groups rather than users (§3.4), short-lived credentials rather than keys (§33.5).

Pitfall. "Identity is the perimeter" is often read as "the network no longer matters", and it is repeatedly cited to justify removing network controls. §35.7 and §35.8 are the correction: the network controls that remain exist to make the identity controls unavoidable, not to duplicate them.

35.2 Device Context §

Device posture is the signal that distinguishes a legitimate user from an attacker holding that user's credentials, because the attacker rarely has the device too.

§4.17 owns device trust and §4.15 owns context-aware access. The composition point is that device state is an input to an access level, which is then bound to a principal — so the device does not authenticate, it qualifies an identity that already did.

The signals that are available — managed status, encryption, screen lock, OS version — are only as good as the enrollment that produces them, which makes device management a prerequisite rather than a control you can add later.

Device context is the weakest signal to rely on alone and the strongest as a second factor in a compound condition. An access level requiring corporate device and corporate network and group membership is far stronger than any of the three, and it is also the one most likely to lock out a legitimate user at an inconvenient moment.

Which is why dry-run access levels exist. §4.15 owns the mechanism; the discipline is the same as everywhere else in this book — deploy in report-only, read what would have been denied, then enforce.

Pitfall. Device signals are collected at some point and consulted later. A device that was compliant when the session began and has since been modified continues to satisfy the condition until the signal is refreshed, which is §35.10's problem appearing in a different guise.

35.3 Workload Identity §

A workload's identity is where zero trust is easiest to achieve completely, because a workload has no password to phish and no user to socially engineer.

§4.3 owns Workload Identity Federation and §4.12 owns Kubernetes Workload Identity. The composition point is that both replace a stored credential with an attested one: the workload proves something about its environment, and an exchange turns that proof into a short-lived token.

That is a genuinely stronger property than anything available for human identity. The proof is a platform assertion — a GKE service account, a GitHub Actions OIDC token, an instance's metadata identity — that cannot be copied off the machine and reused elsewhere, provided the attribute condition is written to pin it (§26.4).

The attribute condition is where this is won or lost. A federation binding accepting any repository in an organization accepts a repository an attacker can create. §4.7 and §26.4 both insist on numeric identifiers for exactly this reason.

The failure mode is the key that was never removed (§33.5). An estate can deploy federation perfectly and remain exactly as exposed as before, because the old key still works. Federation is only a control once constraints/iam.disableServiceAccountKeyCreation is enforced and the existing keys are gone (§31.4).

Pitfall. Workload identity is often deployed for new services and not retrofitted to old ones, producing an estate where the modern path is exemplary and the actual attack surface is unchanged. The measure of success is the count of remaining user-managed keys, not the count of federated workloads.

35.4 Service Identity §

A service account is a principal with no password, no MFA, and no human to notice something is wrong. Everything that makes human identity trustworthy is absent, and this section is what replaces it.

What is missing, and its substitute:

Impersonation is the mechanism that makes service identity auditable. A human or pipeline that impersonates an account produces an audit record naming both parties in serviceAccountDelegationInfo — so an action is attributable to the originating identity rather than to a shared account. §26.3 uses this deliberately.

One account per workload, never one per team. A shared service account destroys attribution and merges blast radius, and the audit log cannot distinguish which of five services made a call.

The actAs boundary is the underrated control. iam.serviceAccounts.actAs governs who may attach an identity to a resource, which is separate from who may impersonate it (§26.4). Without it, anyone who can create a Cloud Run service can run code as any account in the project.

Pitfall. A service account's permissions are usually set once, at deployment, and grow monotonically thereafter (§33.3). Because nothing fails when they are too broad, and because there is no human to complain, service accounts drift further from least privilege than human principals do — the opposite of the usual assumption.

35.5 Context-Aware Access §

§4.15 owns access levels and their conditions. The composition point is that an access level is the one object in GCP that both the identity plane and the network plane consume.

The same access level appears in two places, and this is what makes it the connective tissue of the architecture:

Writing one access level and using it in both places is the design. The conditions — corporate IP range, device policy, geography, required upstream levels — are stated once, and both planes enforce the same statement.

Basic conditions combine with AND within a condition and OR across conditions, which is the single most misread property of the object. A level with two conditions is more permissive than a level with one condition containing both clauses. §4.15 owns the syntax; the consequence is that a level written to be strict can be accidentally written to be loose.

Custom levels take a CEL expression for anything the basic form cannot express.

Pitfall. An access level attached to an ingress rule with ANY_IDENTITY reduces the perimeter to whatever that level permits (§20.5). The level is then doing the work of both authentication and authorization, and if it is IP-based it is doing that work with an IP address — which is precisely the trust this chapter exists to remove.

35.6 IAP §

Identity-Aware Proxy is the clearest policy enforcement point in Google Cloud: it terminates the connection, evaluates identity and context, and only then brokers access to the resource.

§4.16 owns IAP as an access control and §7.17 owns it as a load balancer front door. The composition point is that these are the same mechanism applied at two layers, and together they cover the two ways anyone reaches anything: the application and the administrative interface.

IAP is what allows the network to be closed. An instance with no external IP and no open SSH port is administered through IAP TCP forwarding (§8.21); an internal application with no public address is reached through IAP on a load balancer. In both cases the resource has no network exposure and the enforcement is on identity.

The firewall rule permitting 35.235.240.0/20 is the one piece of network trust the design retains, and it is worth being precise about why that is acceptable: the range is Google's forwarding infrastructure, and a packet from it has already passed IAP's authorization. The network rule is not the control; it is the consequence of the control.

Signed headers are how a backend verifies the claim. A backend that trusts a header without verifying its signature can be reached directly if anything ever bypasses the proxy, and §7.17 owns the verification.

Pitfall. IAP protects the path through IAP. A resource reachable by another route — a second load balancer, a peered network, a VM with an external IP added later — is not protected at all. IAP is a policy enforcement point, and a policy enforcement point that can be bypassed is a suggestion.

35.7 Private Services §

Three mechanisms with confusingly similar names solve three different problems, and getting them right is prerequisite to the argument in §35.8.

The composition point is that private connectivity removes the internet from the path without conferring authorization. Reaching Cloud Storage over restricted.googleapis.com does not grant access to any bucket — IAM still decides — and that separation is what makes private networking compatible with zero trust rather than a return to perimeter thinking.

restricted.googleapis.com is the variant that matters here because it resolves only services a perimeter can protect, which makes it the correct choice inside a VPC Service Controls perimeter (§20.x). private.googleapis.com reaches more services and is the right choice outside one.

Private Service Connect is the strongest of the three for a zero-trust design, because the consumer reaches a specific endpoint in its own VPC rather than a network range: there is no transitive path to anything else, which is the property §35.9 wants.

Pitfall. Private connectivity is regularly presented as a security control by itself, and it is not — it is a reachability control. A private path to a service still allows a compromised workload to call it with whatever permissions it holds. What private connectivity buys is that the path cannot be used from outside, which matters only in combination with §35.8.

35.8 Service Perimeters §

Chapter 20 is the perimeter chapter and owns VPC Service Controls entirely. This section adds exactly one thing: the composition argument for why a perimeter is necessary in a model whose premise is that identity is the control point.

The argument is that identity alone does not survive credential theft. Every control in Chapter 4 answers "is this the right principal". None of them answers "should this principal be able to do this from here". A stolen service account key, a token exfiltrated from a compromised workload, an insider copying data to a personal project — in all three cases the identity is correct and the request is authorized.

A perimeter makes a valid credential useless outside its context. That is the property nothing else in this book provides: an API call with perfect credentials, from outside the perimeter, to a restricted service, fails. It is the control that assumes identity has already failed.

This is why the two are complementary rather than alternative. Identity controls reduce the probability of a stolen credential; a perimeter reduces its value. A design with only the first is one phishing attack away from full data access; a design with only the second trusts everyone inside.

The perimeter's own weak point is its exception mechanism (§20.5), and it fails in the direction this chapter warns about throughout: an ingress rule with ANY_IDENTITY and a broad access level is a hole with a title, and a perimeter left in dry-run is §33.20's theater.

Pitfall. A perimeter is a data-exfiltration control and is regularly deployed as though it were an access control, then blamed for not stopping something it was never evaluating. Chapter 20 states the boundaries — it does not cover NFS and SMB data paths, it does not apply to hierarchical firewalls, and folders and organizations cannot be members.

35.9 Microsegmentation §

Segmentation in a zero-trust model exists to make identity controls unavoidable, not to substitute for them.

§5.31 and §5.32 own segmentation and isolation; §5.16 owns the mechanism that makes it identity-shaped: firewall rules targeting service accounts rather than network tags. That is the specific technique that makes segmentation zero-trust rather than merely traditional — the rule expresses "workloads running as this identity" rather than "hosts someone labelled".

The composition point is that a segment is a blast-radius boundary, not a trust boundary. Inside a segment, workloads still authenticate to each other and still hold their own least-privilege identities. The segment's job is to ensure that a compromised workload cannot reach something it has no business reaching even if its credentials would allow it — and to ensure that reaching anything requires passing an enforcement point that logs.

Deny-by-default egress is the part most estates skip and the part that matters most for containment: it turns lateral movement and exfiltration into a firewall change rather than a network connection.

Secure tags are the other identity-shaped target, and they inherit through the resource hierarchy — which makes them the tool for expressing a policy across projects without enumerating instances.

Pitfall. Segmentation designed by network topology and workload identity designed by team ownership produce two different maps of the same estate, and the seam between them is where over-broad rules accumulate. Derive the segments from the identities (§5.16), and the two maps become one.

35.10 Continuous Authorization §

This is the chapter's own material and the model's weakest point: GCP authorizes at the moment of a request and issues credentials that outlive the conditions that justified them.

The gap, concretely:

Session length is the one lever that is generally available, and it is the concrete answer to "how long is a compromised session useful". It is set on a cloud access binding:

gcloud access-context-manager cloud-bindings create \
  --group-key=GROUP_KEY \
  --organization=123456789012 \
  --session-length=2h \
  --session-reauth-method=SECURITY_KEY

--session-length takes an ISO duration and --session-reauth-method defaults to login; the stronger values require a password or a security key rather than merely a valid session. Shortening the session is the most direct improvement available to a zero-trust design, and it is unglamorous enough that most estates leave the default.

For workloads, the equivalent lever is the token lifetime constraint. constraints/iam.allowServiceAccountCredentialLifetimeExtension permits up to twelve hours; not setting it keeps the maximum at one, which is the safer default and should be a deliberate decision either way (§34.5).

Do not claim continuous re-evaluation. No Google documentation confirms that an access level is re-evaluated mid-session, so the honest architecture assumes it is not: a session authorized under conditions that have since changed continues until it expires or reauthentication is required.

The compensating control is detection. If authorization cannot be withdrawn continuously, the response is to notice — anomalous use of a valid credential is exactly what Event Threat Detection looks for (§16.6), and §34.5's containment is what follows.

Pitfall. Zero trust is frequently presented as continuous verification, and on Google Cloud that is aspirational rather than descriptive. A design that assumes revocation is immediate will have an incident plan with an hour-shaped hole in it, and §34.5 is what fills it.

Chapter Summary §

• NIST SP 800-207's decomposition — policy engine, policy administrator, policy enforcement point — is what turns "zero trust" from a slogan into a design you can check.
• GCP has no single policy enforcement point; enforcement is distributed across IAP, load balancers, VPC Service Controls, and each service's own API.
• Identity without a perimeter means a stolen credential works from anywhere; a perimeter without identity trusts everyone inside; the value is in the overlap.
• Device context qualifies an identity that already authenticated — it does not authenticate — and its signals are only as good as the enrollment producing them.
• Workload identity is stronger than human identity because the proof is a platform assertion that cannot be copied off the machine, provided the attribute condition pins a numeric identifier.
• Federation is only a control once key creation is disabled and existing keys are gone; the measure is remaining keys, not federated workloads.
• Service accounts lack a password, MFA, a watching human, and a session that ends; impersonation supplies the attribution that is otherwise missing.
• iam.serviceAccounts.actAs governs who may attach an identity, which is separate from who may impersonate it.
• An access level is consumed by both the identity plane and the network plane, which makes it the architecture's connective tissue — write it once and use it in both.
• Access level conditions AND within a condition and OR across conditions, so more conditions is more permissive.
• IAP is the clearest enforcement point in GCP, and the 35.235.240.0/20 firewall rule is a consequence of the control rather than the control itself.
• Private Google Access, Private Service Access, and Private Service Connect solve three different problems; private connectivity is a reachability control, never an authorization one.
• A perimeter's unique property is that it makes a valid credential useless outside its context — it is the control that assumes identity has already failed.
• Segmentation targets service accounts and secure tags, not network tags, which is what makes it identity-shaped rather than traditional.
• A segment is a blast-radius boundary, not a trust boundary.
• GCP authorizes at the request and issues credentials that outlive it. Access tokens are not revocable, and no documentation confirms mid-session re-evaluation of an access level.
• --session-length on a cloud access binding is the most direct available improvement, and --session-reauth-method defaults to the weakest value.
• Since authorization cannot be withdrawn continuously, detection plus §34.5's containment is the compensating control.

Security Checklist §

Sources §

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf — NIST SP 800-207: the zero trust tenets and the policy engine, administrator, and enforcement point decomposition (last validated 2026-09-04)
• https://cloud.google.com/access-context-manager/docs/session-controls-for-reauthentication — session length, reauthentication methods, and cloud access bindings (last validated 2026-09-04)
• https://cloud.google.com/iam/docs/service-account-creds — access token lifetimes and short-lived credential types (last validated 2026-09-04)
• https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts — the credential lifetime extension constraint (last validated 2026-09-04)
• https://cloud.google.com/access-context-manager/docs/reference/rest/v1/accessPolicies.accessLevels — access level condition semantics, including how conditions combine (last validated 2026-09-04)
• https://cloud.google.com/vpc/docs/private-access-options — the distinction between Private Google Access, Private Service Access, and Private Service Connect (last validated 2026-09-04)
• https://cloud.google.com/chrome-enterprise-premium/docs/securing-console-and-apis — context-aware access applied to the console and APIs (last validated 2026-09-04)
• https://cloud.google.com/logging/docs/reference/audit/auditlog/rest/Shared.Types/AuditLog — the audit log fields that record impersonation and delegation (last validated 2026-09-04)