Metabase 连接级 Impersonation模拟访问权限完整指南配置、源码原理与实战【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase本指南以 docs/permissions/impersonation.md 为核心系统讲解 Metabase 的Impersonation access模拟访问权限模式如何将 Metabase 的查看数据权限委托给数据库内定义的角色让 SQL 编辑器和查询构建器中的问题都受数据库角色级含行级权限约束。读完本文你将掌握impersonation 支持的数据库范围、与行/列级安全sandboxing的本质区别、从建库角色到配置用户属性的完整实操步骤以及背后SET ROLE/USE ROLE执行链路与单 SELECT 语句校验的源码级原理。Impersonation 权限是什么Impersonation模拟访问是 Metabase 的View data查看数据权限级别之一详见 data.md。启用后管理员可以将查看数据的权限外包给数据库中的角色管理员把**用户属性user attribute**与数据库定义的角色及其权限关联起来。当某用户所属的组将某数据库的 View data 权限设为 Impersonation 时该用户能否查看和查询数据取决于其用户属性所指定的数据库角色被授予的权限。核心机制一句话概括Metabase 在真正执行查询前先把当前用户属性中映射的数据库角色通过SET ROLE或USE ROLE切换到数据库连接上再由数据库引擎按该角色的权限执行语句。因此权限的判定发生在数据库引擎内部而非 Metabase 应用层。从源码结构看该能力位于企业版EE模块 enterprise/backend/src/metabase_enterprise/impersonation/core.clj、driver.clj、middleware.clj、db.clj等而查询处理器通过defenterprise扩展点接入例如 execute.clj 中的set-role-if-supported!在 OSS 版本中是 no-op在企业版中才真正执行角色切换。支持 impersonation 的数据库目前仅以下数据库支持连接级模拟访问ClickHouseMySQLPostgreSQL注意若在 PostgreSQL 中使用视图视图上的行级安全RLS策略仅在Postgres 15 及以上版本生效RedshiftSnowflakeSQL ServerStarburst/Trino在 postgres.clj 中可以看到:connection-impersonation true被声明为 PostgreSQL 驱动支持的能力其他驱动同理通过driver/supports?机制暴露该能力。如果你的需求是根据登录用户切换整个数据库连接而非切换角色请参阅 Database routing数据库路由。Impersonation 与行/列级安全sandboxing的区别两者都用于限制数据可见范围但作用层次完全不同Impersonation在数据库层面设置权限覆盖 SQL 编辑器与查询构建器Impersonation 运行在数据库引擎层面。在执行查询之前先设置角色角色决定了数据库执行语句时应使用哪些权限因此查询结果会被角色权限改变。由于权限由数据库引擎强制实施无论问题是用原生 SQL 编辑器编写的还是在查询构建器中点选出来的都会被统一约束——这正是 impersonation 相比 sandboxing 最大的优势。行/列级安全仅在 Metabase 层面设置权限只作用于查询构建器问题行/列级安全row and column security即 sandboxing运行在Metabase 应用层。由于 Metabase 无法解析任意 SQL 来判断用户能看哪些数据它只能对在查询构建器query builder中组装的问题生效此时 Metabase 能解释查询语义并注入过滤条件。用原生 SQL 编辑器编写的问题不受其约束。典型使用场景示例假设People表包含美国 50 个州的所有客户账户行你希望佛蒙特州Vermont销售团队能够既能在查询构建器中提问题也能使用原生 SQL 编辑器只能查看People表中居住在佛蒙特州的客户账户。实施思路分为两步在数据库中创建带策略的角色例如只允许state VT的行可见在 Metabase 中把该数据库的数据访问设为 Impersonation并让团队用户属性指向该角色。当团队运行查询时Metabase 切换到该角色数据库引擎自然只返回被允许的数据子集。配置连接级模拟访问要让 impersonation 生效需要先在数据库中建好供 Metabase 模拟的角色再在 Metabase 中配置组、用户属性与权限。第 1 步准备 Metabase 的数据库连接账号Impersonation 使用数据库角色执行查询但像 同步、扫描与指纹识别 这类元数据操作仍需一个默认角色来运行。因此 Metabase 连接数据库 所用的账号应当具备该数据库中任何 Metabase 组可能需要的全部访问权限因为 Metabase 正是用这个账号来同步表结构信息的。之后可以在数据库中创建权限更受限的角色如表级或行级安全。当通过 impersonation 把角色传给数据库时引擎会返回数据子集或直接限制查询。Redshift 特例Metabase 用于连接 Redshift 的账号必须是超级用户superuser因为 Metabase 需要执行SET SESSION AUTHORIZATION命令该命令只能由数据库超级用户运行。第 2 步在数据库中创建角色在数据库端而非 Metabase 中完成创建一个新的数据库角色Redshift 中即新建一个 user授予该角色你希望被模拟用户拥有的权限。具体创建角色与授权语法请查阅对应数据库文档也可参考 users, roles, and privileges 入门。以 PostgreSQL 为例下面的 SQL 创建名为vermont_sales_team的角色只允许其选择people表中state列为VT的行CREATE ROLE vermont_sales_team; GRANT SELECT ON ALL TABLES IN SCHEMA PUBLIC TO vermont_sales_team; CREATE POLICY vermont ON people FOR SELECT TO vermont_sales_team USING (state VT); ALTER TABLE people ENABLE ROW LEVEL SECURITY;第 3 步Snowflake 需禁用次要角色若使用SnowflakeMetabase 连接 Snowflake 的账号必须禁用次要角色secondary roles否则每个被模拟的角色都会附带 Metabase 账号被授予的其他角色的全部权限。禁用方式ALTER USER metabase_user SET DEFAULT_SECONDARY_ROLES ();第 4 步创建 Metabase 组Metabase 中包括 impersonation 在内的权限都由组管理因此需要创建新组或选用已有组将人员加入组。建议创建一个测试用户并加入该组便于后续验证 impersonation 是否生效。第 5 步为组内人员分配用户属性通过用户属性把组内人员与数据库角色关联属性的key键可以任意命名属性的value值必须与期望的数据库角色完全一致。例如若已在数据库中创建了角色vermont_sales_team如上文示例可以新增一个名为db_role的用户属性名称可自定并将该人员的db_role属性值设为vermont_sales_team。由于部分数据库区分大小写建议确保属性值与数据库角色名逐字符完全匹配。同一组内不同人员的属性值可以不同但属性 key 必须相同参见组内人员不一定共享相同权限。第 6 步在 Metabase 中配置 impersonation按 Cmd/Ctrl K 打开命令面板搜索Permissions或直接进入AdminPermissionsData选择要关联数据库角色的组选择要配置访问权限的数据库将该数据库的View data设置为Impersonation。该选项仅在已创建用户属性后才会显示。如果 All Users 组对该数据库有更宽松的访问权限例如 Can view会出现警告——因为 Metabase 会取用户在全部组中的最宽松权限。此时需先撤销 All Users 组的数据库访问权限再配置 impersonation。从用户属性下拉框中选择你添加的属性该属性映射到组查询数据库时应使用的角色保存更改。同时不要忘记为组和数据库设置Create queries创建查询权限见 data.md。例如希望用户在被模拟角色的前提下编写 SQL需将 Create queries 设为Query builder and native。第 7 步验证 impersonation 是否生效管理员无法用自己的账号验证因为管理员权限更高见下文所以应创建测试用户、将其加入组并配置好用户属性。验证方法若测试用户的 Create queries 为 Query builder and native新建一个 SQL 问题并确认其只能看到正确数据。沿用上文vermont_sales_team角色运行SELECT * FROM people;确认测试用户只看到佛蒙特州的数据。若测试用户的 Create queries 为 Query builder only在左侧边栏进入Browse data确认用户只能看到其有权限的表和数据。源码级原理角色切换与单语句校验角色如何在查询前生效在企业版 impersonation/driver.clj 中enforced-impersonations-for-db计算当前用户应被强制的模拟策略先取用户所属组对应的 impersonation 策略若用户同时在其他非模拟组拥有对该库的**不受限unrestricted**访问则策略不生效若与 sandbox 策略冲突则直接抛出 Conflicting sandboxing and impersonation policies found 异常connection-impersonation-role从当前用户属性中读取角色名并做三项校验属性缺失、角色非非空字符串、角色恰好等于数据库默认角色都会抛出异常set-role-if-supported!在支持:connection-impersonation的驱动上通过driver/set-role!执行SET ROLE/USE ROLE语句对应文档所述把属性作为字符串传入SET ROLE或USE ROLE命令。这一过程与查询执行深度绑定查询处理器在连接上调用 set-role-if-supported!确保查询在正确的角色上下文中运行。被模拟的查询必须是单条 SELECT 语句使用原生 SQL 编辑器且处于模拟访问下的用户只能编写单条 SELECT 语句。Metabase 会在执行前检查每条原生查询非单条SELECT一律拒绝。公共表表达式WITH与集合操作UNION、INTERSECT、EXCEPT视作单条SELECT可以正常执行。源码依据在 driver/sql.clj 的validate-impersonated-query*它通过sql-tools/is-single-stmt-of-type?解析并判定语句类型读取查询上的:impersonation/allow-write?标记决定要求单条select还是单条写语句自定义写操作由 writeback.clj 设置无法解析的查询一律拒绝非管理员只能运行单条所需类型的语句否则抛出Invalid impersonated native query. Must be a single {0} statement.。会被拒绝的示例查询分号分隔的多条语句如SET ROLE analyst; SELECT * FROM people;创建或修改表的语句CREATE、ALTER、DROP包括临时表切换角色的语句如SET ROLE、USE ROLE组内人员不一定共享相同权限Metabase 使用每条用户属性中为每个人指定的角色。例如选择db_role属性用于 impersonation一个人的db_role可以是sales另一个人的可以是engineering或任何映射到数据库中有效角色的值。因此同一组的成员因属性值不同实际数据权限可能完全不同。用 impersonation 实现行级 SQL 访问你可以利用 impersonation 给用户 SQL 编辑器访问权同时把数据访问限制在特定数据库角色定义的范围内——不仅是表级访问还可以是行级访问或你在数据库中为该角色定义的任何访问级别。实质上你可以在允许用户使用 SQL 编辑器查询的同时实现类似行/列级安全的效果区别在于不在 Metabase 里配置行/列级安全而是在数据库中通过角色授权配置行级安全。如果想给某组某个数据库部分 schema/表的 SQL 访问权可以再创建一个只包含这些表的数据库角色甚至精确到行级然后用 impersonation 把用户属性关联到该角色。Metabase 的做法是取用户属性在执行查询之前作为字符串传入SET ROLE或USE ROLE命令。另外连接级 impersonation 不适用于 Metabase Admins 组——管理员的更高权限优先。Metabase 取所有组中的最宽松权限Metabase 会给用户跨其全部组中最宽松的数据访问权限。假设某人同时属于两个组红色组模拟访问限制其可见数据蓝色组View data 为 Can viewCreate queries 为 Query builder and native。蓝色组的更宽松权限会覆盖模拟访问。管理员看不到 impersonation 的效果管理员永远看不到 impersonation 的效果因为管理员权限会覆盖其所在任何其他组的权限。Metabase 默认的 Administrators 组对所有数据库拥有 Can view 权限且 Metabase 对多组成员取最宽松权限因此任何管理员对该库的权限都是 Can view 而非 Impersonated。要测试 impersonation创建测试用户为其分配带有数据库角色的用户属性加入模拟访问组然后以该测试用户登录验证数据访问。Impersonation 与 Slack 通知处于模拟访问组的用户无法创建Slack 提醒 或 仪表板订阅。邮件提醒与订阅仍然可用。详见 Notification permissions通知权限。【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Metabase 连接级 Impersonation（模拟访问）权限完整指南：配置、源码原理与实战
Metabase 连接级 Impersonation模拟访问权限完整指南配置、源码原理与实战【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase本指南以 docs/permissions/impersonation.md 为核心系统讲解 Metabase 的Impersonation access模拟访问权限模式如何将 Metabase 的查看数据权限委托给数据库内定义的角色让 SQL 编辑器和查询构建器中的问题都受数据库角色级含行级权限约束。读完本文你将掌握impersonation 支持的数据库范围、与行/列级安全sandboxing的本质区别、从建库角色到配置用户属性的完整实操步骤以及背后SET ROLE/USE ROLE执行链路与单 SELECT 语句校验的源码级原理。Impersonation 权限是什么Impersonation模拟访问是 Metabase 的View data查看数据权限级别之一详见 data.md。启用后管理员可以将查看数据的权限外包给数据库中的角色管理员把**用户属性user attribute**与数据库定义的角色及其权限关联起来。当某用户所属的组将某数据库的 View data 权限设为 Impersonation 时该用户能否查看和查询数据取决于其用户属性所指定的数据库角色被授予的权限。核心机制一句话概括Metabase 在真正执行查询前先把当前用户属性中映射的数据库角色通过SET ROLE或USE ROLE切换到数据库连接上再由数据库引擎按该角色的权限执行语句。因此权限的判定发生在数据库引擎内部而非 Metabase 应用层。从源码结构看该能力位于企业版EE模块 enterprise/backend/src/metabase_enterprise/impersonation/core.clj、driver.clj、middleware.clj、db.clj等而查询处理器通过defenterprise扩展点接入例如 execute.clj 中的set-role-if-supported!在 OSS 版本中是 no-op在企业版中才真正执行角色切换。支持 impersonation 的数据库目前仅以下数据库支持连接级模拟访问ClickHouseMySQLPostgreSQL注意若在 PostgreSQL 中使用视图视图上的行级安全RLS策略仅在Postgres 15 及以上版本生效RedshiftSnowflakeSQL ServerStarburst/Trino在 postgres.clj 中可以看到:connection-impersonation true被声明为 PostgreSQL 驱动支持的能力其他驱动同理通过driver/supports?机制暴露该能力。如果你的需求是根据登录用户切换整个数据库连接而非切换角色请参阅 Database routing数据库路由。Impersonation 与行/列级安全sandboxing的区别两者都用于限制数据可见范围但作用层次完全不同Impersonation在数据库层面设置权限覆盖 SQL 编辑器与查询构建器Impersonation 运行在数据库引擎层面。在执行查询之前先设置角色角色决定了数据库执行语句时应使用哪些权限因此查询结果会被角色权限改变。由于权限由数据库引擎强制实施无论问题是用原生 SQL 编辑器编写的还是在查询构建器中点选出来的都会被统一约束——这正是 impersonation 相比 sandboxing 最大的优势。行/列级安全仅在 Metabase 层面设置权限只作用于查询构建器问题行/列级安全row and column security即 sandboxing运行在Metabase 应用层。由于 Metabase 无法解析任意 SQL 来判断用户能看哪些数据它只能对在查询构建器query builder中组装的问题生效此时 Metabase 能解释查询语义并注入过滤条件。用原生 SQL 编辑器编写的问题不受其约束。典型使用场景示例假设People表包含美国 50 个州的所有客户账户行你希望佛蒙特州Vermont销售团队能够既能在查询构建器中提问题也能使用原生 SQL 编辑器只能查看People表中居住在佛蒙特州的客户账户。实施思路分为两步在数据库中创建带策略的角色例如只允许state VT的行可见在 Metabase 中把该数据库的数据访问设为 Impersonation并让团队用户属性指向该角色。当团队运行查询时Metabase 切换到该角色数据库引擎自然只返回被允许的数据子集。配置连接级模拟访问要让 impersonation 生效需要先在数据库中建好供 Metabase 模拟的角色再在 Metabase 中配置组、用户属性与权限。第 1 步准备 Metabase 的数据库连接账号Impersonation 使用数据库角色执行查询但像 同步、扫描与指纹识别 这类元数据操作仍需一个默认角色来运行。因此 Metabase 连接数据库 所用的账号应当具备该数据库中任何 Metabase 组可能需要的全部访问权限因为 Metabase 正是用这个账号来同步表结构信息的。之后可以在数据库中创建权限更受限的角色如表级或行级安全。当通过 impersonation 把角色传给数据库时引擎会返回数据子集或直接限制查询。Redshift 特例Metabase 用于连接 Redshift 的账号必须是超级用户superuser因为 Metabase 需要执行SET SESSION AUTHORIZATION命令该命令只能由数据库超级用户运行。第 2 步在数据库中创建角色在数据库端而非 Metabase 中完成创建一个新的数据库角色Redshift 中即新建一个 user授予该角色你希望被模拟用户拥有的权限。具体创建角色与授权语法请查阅对应数据库文档也可参考 users, roles, and privileges 入门。以 PostgreSQL 为例下面的 SQL 创建名为vermont_sales_team的角色只允许其选择people表中state列为VT的行CREATE ROLE vermont_sales_team; GRANT SELECT ON ALL TABLES IN SCHEMA PUBLIC TO vermont_sales_team; CREATE POLICY vermont ON people FOR SELECT TO vermont_sales_team USING (state VT); ALTER TABLE people ENABLE ROW LEVEL SECURITY;第 3 步Snowflake 需禁用次要角色若使用SnowflakeMetabase 连接 Snowflake 的账号必须禁用次要角色secondary roles否则每个被模拟的角色都会附带 Metabase 账号被授予的其他角色的全部权限。禁用方式ALTER USER metabase_user SET DEFAULT_SECONDARY_ROLES ();第 4 步创建 Metabase 组Metabase 中包括 impersonation 在内的权限都由组管理因此需要创建新组或选用已有组将人员加入组。建议创建一个测试用户并加入该组便于后续验证 impersonation 是否生效。第 5 步为组内人员分配用户属性通过用户属性把组内人员与数据库角色关联属性的key键可以任意命名属性的value值必须与期望的数据库角色完全一致。例如若已在数据库中创建了角色vermont_sales_team如上文示例可以新增一个名为db_role的用户属性名称可自定并将该人员的db_role属性值设为vermont_sales_team。由于部分数据库区分大小写建议确保属性值与数据库角色名逐字符完全匹配。同一组内不同人员的属性值可以不同但属性 key 必须相同参见组内人员不一定共享相同权限。第 6 步在 Metabase 中配置 impersonation按 Cmd/Ctrl K 打开命令面板搜索Permissions或直接进入AdminPermissionsData选择要关联数据库角色的组选择要配置访问权限的数据库将该数据库的View data设置为Impersonation。该选项仅在已创建用户属性后才会显示。如果 All Users 组对该数据库有更宽松的访问权限例如 Can view会出现警告——因为 Metabase 会取用户在全部组中的最宽松权限。此时需先撤销 All Users 组的数据库访问权限再配置 impersonation。从用户属性下拉框中选择你添加的属性该属性映射到组查询数据库时应使用的角色保存更改。同时不要忘记为组和数据库设置Create queries创建查询权限见 data.md。例如希望用户在被模拟角色的前提下编写 SQL需将 Create queries 设为Query builder and native。第 7 步验证 impersonation 是否生效管理员无法用自己的账号验证因为管理员权限更高见下文所以应创建测试用户、将其加入组并配置好用户属性。验证方法若测试用户的 Create queries 为 Query builder and native新建一个 SQL 问题并确认其只能看到正确数据。沿用上文vermont_sales_team角色运行SELECT * FROM people;确认测试用户只看到佛蒙特州的数据。若测试用户的 Create queries 为 Query builder only在左侧边栏进入Browse data确认用户只能看到其有权限的表和数据。源码级原理角色切换与单语句校验角色如何在查询前生效在企业版 impersonation/driver.clj 中enforced-impersonations-for-db计算当前用户应被强制的模拟策略先取用户所属组对应的 impersonation 策略若用户同时在其他非模拟组拥有对该库的**不受限unrestricted**访问则策略不生效若与 sandbox 策略冲突则直接抛出 Conflicting sandboxing and impersonation policies found 异常connection-impersonation-role从当前用户属性中读取角色名并做三项校验属性缺失、角色非非空字符串、角色恰好等于数据库默认角色都会抛出异常set-role-if-supported!在支持:connection-impersonation的驱动上通过driver/set-role!执行SET ROLE/USE ROLE语句对应文档所述把属性作为字符串传入SET ROLE或USE ROLE命令。这一过程与查询执行深度绑定查询处理器在连接上调用 set-role-if-supported!确保查询在正确的角色上下文中运行。被模拟的查询必须是单条 SELECT 语句使用原生 SQL 编辑器且处于模拟访问下的用户只能编写单条 SELECT 语句。Metabase 会在执行前检查每条原生查询非单条SELECT一律拒绝。公共表表达式WITH与集合操作UNION、INTERSECT、EXCEPT视作单条SELECT可以正常执行。源码依据在 driver/sql.clj 的validate-impersonated-query*它通过sql-tools/is-single-stmt-of-type?解析并判定语句类型读取查询上的:impersonation/allow-write?标记决定要求单条select还是单条写语句自定义写操作由 writeback.clj 设置无法解析的查询一律拒绝非管理员只能运行单条所需类型的语句否则抛出Invalid impersonated native query. Must be a single {0} statement.。会被拒绝的示例查询分号分隔的多条语句如SET ROLE analyst; SELECT * FROM people;创建或修改表的语句CREATE、ALTER、DROP包括临时表切换角色的语句如SET ROLE、USE ROLE组内人员不一定共享相同权限Metabase 使用每条用户属性中为每个人指定的角色。例如选择db_role属性用于 impersonation一个人的db_role可以是sales另一个人的可以是engineering或任何映射到数据库中有效角色的值。因此同一组的成员因属性值不同实际数据权限可能完全不同。用 impersonation 实现行级 SQL 访问你可以利用 impersonation 给用户 SQL 编辑器访问权同时把数据访问限制在特定数据库角色定义的范围内——不仅是表级访问还可以是行级访问或你在数据库中为该角色定义的任何访问级别。实质上你可以在允许用户使用 SQL 编辑器查询的同时实现类似行/列级安全的效果区别在于不在 Metabase 里配置行/列级安全而是在数据库中通过角色授权配置行级安全。如果想给某组某个数据库部分 schema/表的 SQL 访问权可以再创建一个只包含这些表的数据库角色甚至精确到行级然后用 impersonation 把用户属性关联到该角色。Metabase 的做法是取用户属性在执行查询之前作为字符串传入SET ROLE或USE ROLE命令。另外连接级 impersonation 不适用于 Metabase Admins 组——管理员的更高权限优先。Metabase 取所有组中的最宽松权限Metabase 会给用户跨其全部组中最宽松的数据访问权限。假设某人同时属于两个组红色组模拟访问限制其可见数据蓝色组View data 为 Can viewCreate queries 为 Query builder and native。蓝色组的更宽松权限会覆盖模拟访问。管理员看不到 impersonation 的效果管理员永远看不到 impersonation 的效果因为管理员权限会覆盖其所在任何其他组的权限。Metabase 默认的 Administrators 组对所有数据库拥有 Can view 权限且 Metabase 对多组成员取最宽松权限因此任何管理员对该库的权限都是 Can view 而非 Impersonated。要测试 impersonation创建测试用户为其分配带有数据库角色的用户属性加入模拟访问组然后以该测试用户登录验证数据访问。Impersonation 与 Slack 通知处于模拟访问组的用户无法创建Slack 提醒 或 仪表板订阅。邮件提醒与订阅仍然可用。详见 Notification permissions通知权限。【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考