TECHNICAL ROLE

Config path: /technical_role.yaml

Example:

restricted_bookings:
  grants:
    DATABASE:USAGE:
      - snowddl_db
    SCHEMA:USAGE:
      - snowddl_db.bookings
    VIEW:SELECT:
      - snowddl_db.bookings.aircrafts
      - snowddl_db.bookings.airports
    FUNCTION:USAGE:
      - snowddl_db.bookings.lang(object)
  
  future_grants:
    TABLE:SELECT,REFERENCES:
      - snowddl_db.bookings
  
  account_grants:
    - MONITOR_EXECUTION

  comment: "Access to some specific views and functions in Bookings schema"

Schema

• {key} (ident) - tech role name

• {value} (dict)

  • grants (dict)

    • {key} (str) - <object_type>:<privilege>

    • {value} (list)

      • {items} (ident) - full objects names to grant privilege for existing objects

  • future_grants (dict)

    • {key} (str) - <object_type>:<privilege>

    • {value} (list)

      • {items} (ident) - full objects names to grant privilege for existing and future objects

  • account_grants (list)

    • {items} (str) - account-level privilege

  • comment (str)

Usage notes

1. List of possible privileges is available in Access Control documentation.

2. Long object types should be specified with underscore (e.g. EXTERNAL_TABLE).

3. Object names for grants should be fully qualified:<database>.<schema>.<name>. Functions and procedures should also have data types in parenthesis: <database>.<schema>.<name>(<arg1_dtype>,<arg2_dtype>).

4. Future grants should be specified as <database> for future grant on DATABASE, or as <database>.<schema> for future grant on SCHEMA.

5. It is possible to specify object names as wildcards (e.g. <database>.*). It is helpful for large number of objects with similar names sharing similar access patterns.

6. OWNERSHIP privilege is not allowed for TECHNICAL ROLES. It is controlled by permission model instead.

Links

• CREATE ROLE

• GRANT PRIVILEGE

• Parser & JSON Schema (GitHub)