Google Identity-Aware Proxy

Implemented production verification of IAP identity assertions with an optional email restriction, while retaining a local passcode fallback. The code path and required audience configuration were documented but could not be tested behind a real IAP deployment.

What worked

It provided a clear production security boundary without moving identity handling into the browser application.

What got in the way

Live token verification, audience matching, and deployment behavior remained unassessed because no deployed backend or IAP configuration was present.

Identity-Aware Proxy was incorporated into the bootstrap design to protect every service route without adding application-level authentication. Its direct Cloud Run integration and no-charge pricing were compelling, though the IAM and service-agent setup required careful handling.

What worked

The documentation supported a clear edge-authentication design and avoided the need for a separate paid load balancer or custom authentication code.

What got in the way

The access policy was not applied live because administrator authentication and staff identity details were unavailable in the environment.

Selected direct IAP and encoded its access policy in Terraform so an otherwise unauthenticated API would not be publicly exposed. Provider resource details and identity assumptions needed careful verification; no live authentication flow was exercised.

What worked

Direct protection of the default service URL addressed the application's most important exposure risk without requiring custom authentication code.

What got in the way

Authorized group details and the target organization's identity setup were unavailable, so end-to-end access could not be validated.

Direct IAP was chosen to place a Google sign-in gate in front of all Cloud Run routes without adding a paid load balancer. The access model addressed a serious exposure in the application, but identities and policies could not be applied or tested live.

What worked

The documented direct integration matched the need for staff-only access and kept the architecture and expected monthly cost small.

What got in the way

The workspace lacked project authentication, so login behavior, user authorization, and protection of the default service URL were not observed.

Researched and configured direct IAP on Cloud Run so all ingress stays private to an approved staff group, while accounting for service-agent invocation by monitoring. The configuration validated but was not applied.

What worked

Direct Cloud Run integration avoided adding custom authentication code and kept access control in managed infrastructure.

What got in the way

Service-agent IAM interactions required several documentation searches and could not be verified against a live project.

Selected and configured Identity-Aware Proxy as the staff sign-in layer for the private Cloud Run service. The documentation established that direct protection of the default service URL was supported, but identity grants and final enablement could not be completed without the cloud account and staff addresses.

What worked

It provided a credible way to add staff-only Google sign-in without building or operating an authentication service.

What got in the way

Some setup details were difficult to automate fully and depended on account-specific identities and permissions that were unavailable.