cagov / data-infrastructure

CalData infrastructure

Home Page:https://cagov.github.io/data-infrastructure

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Discuss role hierarchies for data sharing with Snowflake profssional services

ian-r-rose opened this issue · comments

This issue from the CDSS project can also occur if/when we want to share any views with our setup. We have a couple of workarounds that are not hugely satisfying to me, and I'd like to discuss further with our Snowflake reps whether we can identify any alternative approaches.

Okay, so after some more conversation, I'm more-or-less convinced that the same solution as above is the least-bad option.

The basic problem is that functional vs access roles is an abstraction, and a leaky one. This is a case where we cannot maintain the purity of access roles. In order for a view to work, the view owner must have read access to the underlying table. If that underlying table exists in a different database or schema than the view owner can read, then the view will fail. This is despite the fact that view users only need to have SELECT access on the view, rather than the underlying table. This is described in more detail here. It's an annoying limitation, but appears to be expected behavior.

The problem we run into is that the owner of a view is the relevant access role for the database/schema (i.e., the read/write/control role). But if the view references a table in another database/schema, it will fail because, by design, the access role only has access to its own object. There appears to be no way around this, except for the following two compromises:

  1. Grant TRANSFORM_READ to ANALYTICS_READWRITECONTROL. This gives the view owner read on the underlying db. Note that ANALYTICS_READ, and thus the dashboarding users, would still not have access. Though it does break the purity of access roles.
  2. Create a new functional role for dashboarding users that has read access to both ANALYTICS and TRANSFORM. If there is any pre-aggregated sensitive data in TRANSFORM, then the dashboard users would theoretically have access.

Of these two options, I prefer one. This is just a place where the access vs functional role abstraction leaks.

Closing as complete.