BigQuery服务账号行级权限（Row-Level Security）配置后查询返回空的问题排查

看起来你遇到的问题是服务账号在应用行访问策略（RAP）后查询返回空，但用户/组使用相同策略却正常，移除策略后服务账号能访问全表——这说明基础权限没问题，问题大概率出在行访问策略的配置或服务账号的身份处理上。下面是一步步的排查和解决思路：

1. 先确认行访问策略的配置准确性 #

首先要确保你的RAP确实正确授予了目标服务账号，没有拼写错误：

• 运行以下命令查看表的RAP详情：

  bq show --format=prettyjson <project>.<dataset>.planets | jq '.rowAccessPolicies[]'
  

  检查返回结果里的grantees字段，确认服务账号的邮箱完全匹配（包括项目ID部分，比如account_name@<project>.iam.gserviceaccount.com），同时filterExpression确实是has_aliens = false。

  如果发现邮箱拼写错误，直接重新创建RAP即可：

  CREATE OR REPLACE ROW ACCESS POLICY aliens_filter ON `<project>.<dataset>.planets`
  GRANT TO ("serviceAccount:<正确的账号邮箱>")
  FILTER USING (has_aliens = false);
  

2. 检查是否存在多个行访问策略 #

BigQuery的多个行访问策略之间是逻辑AND的关系——也就是说，服务账号必须满足所有RAP的过滤条件才能返回数据。如果你的表上还有其他RAP，而那个策略的过滤条件和当前的has_aliens = false没有交集，就会导致返回空结果。

用刚才的bq show命令查看所有RAP，确认只有你创建的aliens_filter这一个，或者其他RAP的条件和当前条件有匹配的行。

3. 验证服务账号查询时是否应用了RAP #

在BigQuery控制台的查询历史里找到服务账号执行的查询，查看详情页的查询信息部分，看是否有Row access policies applied的标注。如果没有，说明RAP没有被正确应用，可能是服务账号的角色或身份问题：

• 确认服务账号只被授予了roles/bigquery.filteredDataViewer角色，而没有同时授予roles/bigquery.dataViewer——虽然dataViewer不会覆盖RAP，但如果存在其他权限冲突，可能导致RAP不生效（不过你移除RAP后能查全表，这个可能性较低，但可以确认一下）。

4. 排查IAM条件限制 #

如果你的服务账号的角色绑定带有IAM条件（比如限制访问时间、IP地址等），这些条件会和RAP的过滤条件结合。比如，如果IAM条件限制服务账号只能在特定时间访问，而你测试的时间不在范围内，就会返回空结果。

到Google Cloud IAM控制台查看服务账号的角色绑定，确认没有额外的条件限制。

5. 重新创建RAP并测试 #

如果以上都没问题，尝试删除并重新创建RAP，有时候BigQuery的配置同步会有延迟：

DROP ROW ACCESS POLICY aliens_filter ON `<project>.<dataset>.planets`;

CREATE ROW ACCESS POLICY aliens_filter ON `<project>.<dataset>.planets`
GRANT TO ("serviceAccount:<account_name>@<project>.iam.gserviceaccount.com")
FILTER USING (has_aliens = false);

然后用服务账号重新执行查询，看是否返回预期的结果（排除has_aliens = true的火星行）。

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