BigQuery远程函数调用Cloud Function Gen2报Access denied咨询

• 使用BigQuery远程函数搭配第一代Cloud Function时，存在高实例数扩容上限，最高仅能激活60个实例，无法支撑高并发场景
• 部署代码、基础配置、网络规则、绑定服务账号完全一致的第二代Cloud Function后，在BigQuery Web界面调用时返回Access denied错误
• 已确认所用BigQuery连接已配置invoke调用权限：同一连接调用第一代Cloud Function无访问报错、可正常运行，仅调用第二代Cloud Function时报错
• 第二代函数调用报错截图：
  
• 复现测试SQL：

CREATE OR REPLACE FUNCTION `project_name`.trash.add_fake_first_gen(user_id int64, corp_id STRING) RETURNS STRING REMOTE
WITH CONNECTION `project_name.eu.gcf-con` OPTIONS (endpoint = 'first_gen_url',  max_batching_rows=1);
SELECT`project_name.trash.add_fake_first_gen`(1, "B");

CREATE OR REPLACE FUNCTION `project_name`.trash.add_fake_second_gen(user_id int64,  corp_id STRING) RETURNS STRING REMOTE
WITH CONNECTION `project_name.eu.gcf-con` OPTIONS (endpoint = 'second_gen_url', max_batching_rows=1);
SELECT `project_name.trash.add_fake_second_gen`(1, "B");

• 两代函数配置参考：
  • 正常运行的第一代Cloud Function配置：
    
  • 访问报错的第二代Cloud Function配置：
    

第二代Cloud Function底层基于Cloud Run实现，和第一代函数的权限、流量控制逻辑完全不同，哪怕代码、服务账号、网络配置和第一代完全一致，也必须补做以下配置才能被BigQuery远程函数正常调用：

• 补全Cloud Run层面的调用权限：第一代函数的调用权限校验走Cloud Functions原生IAM，仅需要给BigQuery连接的服务账号绑定roles/cloudfunctions.invoker即可；第二代函数的调用权限校验走底层Cloud Run的IAM逻辑，必须额外给同一个连接服务账号绑定roles/run.invoker角色，否则会直接返回Access denied，这也是绝大多数同场景报错的核心原因
• 调整入站流量控制规则：第二代函数默认入站规则为「仅内部流量」，该规则下公网来源、跨项目的BigQuery服务调用流量会被直接拦截，需要根据实际网络场景将入站规则调整为「允许所有流量」，或通过VPC对等、Private Google Access配置将BigQuery调用流量纳入内部流量范畴
• 校验触发URL格式：第二代函数默认触发URL域名为<region>-<project-id>.run.app，不要沿用第一代函数的cloudfunctions.net域名格式，填写远程函数endpoint时要写全完整HTTPS地址，不要遗漏路径后缀
• 检查VPC服务边界规则：如果配置了VPC Service Controls，需要将BigQuery服务和第二代Cloud Function对应的Cloud Run资源纳入同一个服务边界，否则跨边界的调用请求会被权限拦截

以上配置全部完成后，等待IAM权限全局生效（通常30秒到2分钟），不需要重建BigQuery远程函数，直接重新执行调用SQL即可正常运行。第二代Cloud Function最高支持1000个并发实例，可彻底解决第一代函数最高60实例的扩容瓶颈。

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