GitHub user bharos added a comment to the discussion: Consider support for role assumption (SET ROLE) to narrow effective permissions
1. Least-privilege enforcement at runtime. A specific workload should only touch 5 tables even though the identity can touch 105. If that workload misbehaves (bug, misconfigured join, compromised credential), the blast radius is bounded. This is the core rationale behind Snowflake's USE ROLE and Hive's SET ROLE — both exist precisely for this scenario. 2. Audit and compliance. When a pipeline operates under restricted_role, any access outside those 5 tables is a hard deny. You get a clean audit signal: "this workload attempted out-of-scope access" vs. "it silently succeeded and we have to figure out intent from logs after the fact." Some data governance policies require explicit opt-in to elevated access. 3. Migration parity. For context — SET ROLE is an existing capability in Hive with SQL Standard Authorization. Teams migrating table formats to Iceberg (which goes through Gravitino's REST catalog) would lose this capability. Being able to narrow the active role via the header approach restores parity without requiring engine-side changes. To directly answer your question: it's not about the user wanting less access , it's about the workload operating with only the access it needs. GitHub link: https://github.com/apache/gravitino/discussions/10894#discussioncomment-16773165 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
