GitHub user markhoerth added a comment to the discussion: Consider support for role assumption (SET ROLE) to narrow effective permissions
Thanks for raising this, @bharos. A few things would help the discussion reason about this more concretely: Use case. Could you walk through the specific scenario driving this? In particular: (1) is this primarily for service-account workloads where one identity needs different effective permissions for different jobs, or for interactive users with multiple roles, or both? (2) what's the current workaround — separate catalogs per role, accepting the over-grant exposure, separate service identities? (3) is the narrowing requirement static (per-pipeline configuration) or dynamic (changes during a single workload's lifetime)? The right approach depends a lot on which of these is the dominant case. Style of narrowing. Header-based per-request narrowing is one option; another is encoding the activated role set into the auth token itself, typically via OAuth scope at token issuance. Some other products in this space take the scope-based approach, so it's worth weighing alongside the header design. A few architectural properties to consider: the activated role set becomes a characteristic of the session/token rather than a per-request parameter, which means a token can't be widened by an attacker manipulating headers — it's bound to its narrowed set at issuance. It also opens the door to additional issuance-time checks (time-of-day, MFA, source-IP) where the IdP path supports them. Header-based narrowing is simpler to implement and may still be the right answer; both approaches are worth weighing. Dynamic vs. static. True dynamic mid-session role switching (the SQL USE ROLE model) is a meaningfully larger effort — server-side session state, engine cooperation to propagate the switch — and would need a specific use case to justify. The connection-time / token-issuance-time narrowing covers most practical cases without those costs. If your scenario really needs mid-session switching rather than per-connection or per-token narrowing, it'd be worth hearing why explicitly. GitHub link: https://github.com/apache/gravitino/discussions/10894#discussioncomment-16764518 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
