We have completed a reproducible, fail-closed diagnostic in us-central1.
Verified configuration
-
Next-hop Secure Web Proxy with a correctly attached gateway security policy.
-
Source Compute Engine VM:
10.250.244.3, private IP only. -
Attached, enabled service account:
helixis-ci-swp-probe@studio-1130431360-48a05.iam.gserviceaccount.com. -
Priority 60:
destination.port == 443 && source.matchServiceAccount('...')— DENY. -
Priority 70:
source.matchServiceAccount('...')— DENY. -
Priority 80:
host() == 'fhir.epic.com'— DENY. -
No active ALLOW rules or authorization-policy override.
Observed transactions — 2026-11-04 at approximately 04:02:17 UTC
-
Correct SNI (
fhir.epic.com) → hostname-only DENY, priority 80. -
Incorrect SNI (
example.com) → default DENY. -
No SNI → default DENY.
All three connections reached the SWP gateway from the expected VM address. Priority 60 and 70 did not match any transaction.
The complete JSON payloads contain enforcedGatewaySecurityPolicy.matchedRules but no clientServiceAccount field or other source-identity information.
The test completed safely. Two independent recovery workflows successfully stopped the VM, removed its diagnostic firewall authorization tag, disabled the temporary firewall exception, and verified final isolation. Temporary IAM privileges were revoked.
Request for Google Cloud engineering clarification
-
Should
source.matchServiceAccount()recognize a Compute Engine VM's attached service account inNEXT_HOP_ROUTING_MODEwhen using a tagged staticnext-hop-ilbroute? -
Are there undocumented source-identity attribution prerequisites or mode-specific limitations?
-
How can we verify whether source identity is unavailable, omitted from logging, or evaluated as nonmatching?
-
Do the VM's OAuth access scopes affect SWP source identity attribution?
We can provide sanitized transaction records and exact timestamps for investigation. We require service-account-based authorization and will not enable a hostname-only ALLOW rule.
