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

PreviousTASKNextUSER

Last updated