GCP内部网络中使用Firebase实现用户私有认证的方案咨询

核心背景说明 #

Firebase Auth的前端SDK依赖公网的firebaseapp.com域名资源（比如认证iframe），目前这些资源没有原生私有端点，所以纯私有网络环境下直接用前端SDK会遇到访问障碍。以下是几种可行的适配方案：

方案1：Cloud NAT + 私有DNS结合Serverless VPC Access #

如果你的Cloud Run已配置Serverless VPC Access，可以通过以下步骤让内部流量访问Firebase Auth资源：

• 确保Cloud Run服务已关联VPC连接器，让服务出站流量进入你的VPC网络。
• 为VPC部署Cloud NAT，允许VPC内的流量（包括Cloud Run通过连接器发出的）通过NAT访问Firebase Auth的公网资源。
• 配置Cloud DNS私有区域，将firebaseapp.com及其子域名解析到对应公网IP，同时给私有IP的Windows机器配置Cloud DNS，确保它能正常解析这些域名并通过Cloud NAT访问公网资源。
• 注意：这种方案下前端仍会访问公网资源，但所有流量都通过GCP内部网络的NAT出口，不会暴露你的资源公网IP。

方案2：服务端侧Firebase认证（完全私有交互） #

把认证逻辑移到后端，避免前端直接访问公网资源：

• 前端（内部Cloud Run服务）收集用户认证凭证（如邮箱密码、第三方授权码），发送到后端Cloud Run服务。
• 后端使用Firebase Admin SDK处理认证请求，通过Serverless VPC Access + Cloud NAT访问Firebase Auth的公网API（后端流量走内部VPC通道，无需公网IP）。
• 这种模式下，前端仅与内部后端服务交互，完全在私有网络内完成认证流程的前端部分。

方案3：替换为Cloud Identity-Aware Proxy（IAP） #

如果场景允许替换认证方式，IAP更适配私有网络环境：

• 为内部Ingress的Cloud Run服务配置IAP，用户访问时通过IAP完成认证，IAP可与Google Workspace或Cloud Identity集成。
• IAP支持私有网络内的访问流程，无需依赖Firebase Auth的公网资源，完全符合GCP内部网络运行要求。

Serverless VPC Access在场景中的作用 #

Serverless VPC Access的核心作用是让无服务器的Cloud Run服务接入你的VPC网络：

• 让Cloud Run后端的认证请求通过VPC连接器进入内部网络，再通过Cloud NAT访问Firebase Auth的公网API，避免服务直接暴露公网出口。
• 确保Cloud Run服务能与VPC内的其他私有资源（如你的Windows机器）正常通信。

关键配置注意事项 #

• 配置VPC防火墙规则，允许VPC连接器与Cloud NAT的流量，以及Windows机器到Cloud Run服务的内部流量。
• 若选择方案1，需确保Windows机器使用Cloud DNS私有区域解析firebaseapp.com域名。
• 若要求完全隔离公网，目前Firebase Auth前端SDK无法实现，只能采用服务端认证或IAP替换方案。

内容的提问来源于stack exchange，提问作者vikrantx