Starburst Galaxy

  • Starburst Galaxy Home
  • Get started
  • Get support
  •   Global features
  • Release notes
  • Feature release types

  • Starburst Galaxy UI
  •   Query
  •   Catalogs
  •   Catalog explorer
  •   Data products
  •   Clusters
  • Partner connect
  •   Admin
  •   Access control
  •   Cloud settings

  • Administration
  •   Security
  •   Single sign-on
  •   Troubleshooting
  • Galaxy status

  • Reference
  • API
  •   SQL
  •   Tutorials
  • Policies #

    A policy supplies privileges to an entity such as a catalog, schema, table, view, or column, based on the entity’s assigned attributes, such as tags.

    A policy has the following characteristics:

    Attribute Description
    Name and description The name and description given to the policy upon creation.
    Matching expression A boolean expression that can test whether tags are associated with an entity. Tags can be associated with one or more catalogs, schemas, tables, views, or columns.
    A role that the policy is assigned to The policy is only active if the policy role is contained in the user's current active role set.
    Grants of privileges on entities A set of privileges that can either be granted or denied. You can identify all tables in a catalog by selecting All schemas and All tables in the Scope section of the Policies tab. The entities on which policies can grant privileges are catalogs, schemas, tables, views, and columns.
    Combined privilege checks with role-based privileges When checking privileges, role-based privileges and attribute-based privileges from policies are combined using the same rules as are used for multiple role-based privileges:

    • ALLOW privileges are additive, so the allowed privileges on the entity are the union of role-based and attribute-based ALLOW privileges from either source.
    • However, a DENY privilege from either role-based or attribute-based privileges overrides an ALLOW privilege from either source.

    Matching expressions #

    The matching expression is a boolean expression that uses parentheses and the AND, OR and NOT operators. HAS_TAG(example_tag) is a special function operator that is applied using the name of a tag as a parameter. If the tag is associated with the set of tags on an entity, it returns true. As with SQL expressions, matching expression operators are case-insensitive, but by convention are usually written as uppercase.

    Matching expressions do not refer to entities directly. They only refer to the tags associated with an entity. This means that the same policy can apply to a catalog, schema, table, view, or column.

    The following example shows a matching expression that tests if the set of tags on an entity includes the tag sales_department and does not include the tag pii:

    HAS_TAG(sales_department) AND NOT HAS_TAG(pii)
    

    The following example shows a matching expression that returns true if either the set of tags on an entity includes the tag sales_department or includes tag marketing_department as well as tag sales_liaison:

    HAS_TAG(sales_department) OR (HAS_TAG(marketing_department) AND HAS_TAG(sales_liaison))
    

    Policy grants #

    A policy can define grants on multiple entities, and a single policy can grant privileges on different entity kinds. For example, a policy named sales_admin might allow the CREATE_TABLE privilege on all schemas in a catalog named sales_data and allow privileges SELECT, UPDATE and INSERT on all tables in catalog sales_data.

    Defining policies #

    The Policies tab lists all policies. The tab is only visible if a role in the user’s active role set has the account-level privilege MANAGE_SECURITY.

    If some role in the user’s active role set has the MANAGE_SECURITY privilege, the user can create a new policy by clicking Add policy.

    When creating a policy, you can enter the matching expression as free text in the matching expression input field. For each character typed, the expression parser is run, and the input field turns pink if there is a syntax error in the matching expression, or if it references a tag that does not exist.

    You can change any attribute of a policy listed in the policies tab by clicking .

    Policy grants and privilege checking #

    The Starburst Galaxy access control system performs the following operations to check whether the user has access to a catalog, schema, table, view, or column entity:

    • The tags associated with the catalog, schema, table, view, or column are fetched. Because of tag inheritance, a tag applied to a catalog is returned in the set of tags for any schema, table, view, or column in the catalog. Similarly, a tag applied to a schema is returned in the set of tags for any table, view, or column in the schema. Finally, a tag applied to a table or view is returned in the set of tags for any column in the table or view.
    • The system evaluates the matching expression for all policies based on the tags associated with the entity. The system collects the privileges granted by the policies on the entity for which the matching expressions are true.
    • Role-based grants for the entity are retrieved and combined with the policy grants. The usual rules for ALLOW and DENY privilege grants are applied, so a DENY privilege always overrides an ALLOW privilege whether the privileges come from role-based grants or from attribute-based grants.

    Policy grants and catalog, schema, table, and view visibility #

    A key operation performed by the access control system determines visibility of catalogs, schemas, tables, and views:

    • A catalog is visible to a user if a role in the user’s active role set owns the catalog, or has an ALLOW privilege on the catalog or any schema, table, view, or column in the catalog, and that the ALLOW privilege is not overridden by a DENY privilege. The privileges can come from role-based grants, or from policies whose matching expression is true for the tags associated with a tagged entity in the catalog.
    • Similarly, a schema is visible to a user if a role in the user’s active role set owns the schema, or has an ALLOW privilege on the schema or any table, view, or column in the schema, and that the ALLOW privilege is not overridden by a DENY privilege. The privileges can come from role-based grants, or from policies whose matching expression is true for the tags associated with a tagged entity in the schema.
    • Finally, a table or view is visible to a user if a role in the user’s active role set owns the table or view, or has an ALLOW privilege on the table or view, or any column in the table or view, and that the ALLOW privilege is not overridden by a DENY privilege. The privileges can come from role-based grants, or from policies whose matching expression is true for the tags associated with a tagged entity in the table or view.