Support tag-based role definitions

Part of the Managed Roles feature.

Should support the following definitions:

Role pii_viewer has access to tables tagged with pii
Role non_pii_viewer has access to all tables except tables tagged with pii
Role sales_manager has access to all tables tagged as sales

Proposed YAML

rolesGrants:
  engineering:
    sub_roles:
      - acme_prod_call_center_reader
      - acme_prod_catalog_page_reader
      - pii_viewer

  pii_viewer: # programmatically generated - do not edit this role!
    select:
      tables:
        - pii_table_1
        - pii_table_2

  non_pii_viewer: # programmatically generated - do not edit this role!
    select:
      tables:
        - acme.prod.call_center
        - acme.prod.catalog_page

managedRoles:
  pii_viewer:
    select:
      any_table_with_tag: pii

  non_pii_viewer:
    select:
      all_tables_except_tag: pii

Implementation: Managed Roles

Managed roles are programmatically generated and updated by Spyglass.

Tags are used as high level policy (or intent) to describe what tables a role should have access to.

For example,

Role pii_viewer should have read access to tables tagged pii.
To achieve this, Spyglass queries all tables tagged pii.
Then Spyglass grants privileges on pii_viewer for the resulting tables.
Users are prevented from updating the pii_viewer role manually in YAML.
Periodic calls to sync --managed will ensure the role stays up to date with tag changes.

What Else Should Be Expressible?

There could be more complex policies to express, for example:

Role accounting should be able to view any tables with tags (accounts_payable OR accounts_receivable) AND NOT soc2.

This would make the language much more powerful, but at the cost of being more complicated. It may be some kind of "expert mode" we allow for, when the need arises.

Alternative Considered: Row Level Access Policies

We could use row level access policies (for example), but they would need to be maintained across every table in the account. This potentially results in extra cost (in both credits and performance) to all queries, in addition to creating a more complex access story. That said, we may still pursue this approach in the near future.

spyglasshq / spyglass-cli