Assigning access rules for tables in Managed Service for Trino

Written by

Yandex Cloud

Updated at March 17, 2026

Setting rules when creating a cluster
Setting rules for an existing cluster
Example of setting table access rules

Rules define the actions users can perform with tables in a Managed Service for Trino cluster.

For each user-table pair, rules apply as follows:

Rules are checked for matches in the order they are specified in the configuration file. The first rule matching the user-table pair applies.
If none of the rules match the user-table pair, no actions with the table are allowed to the user.
If no table access rules are set, any user can perform any actions with any table.
Table access rules apply together with the top-level rules for objects in catalogs.

Setting rules when creating a cluster

You can set table access rules when creating a Managed Service for Trino cluster.

Warning

Names of tables and schemas specified in rules are not validated. If a table name or a schema name contains an error, the rule will not apply correctly.

Management console

CLI

Terraform

gRPC API

In the management console, select the folder where you want to create a Managed Service for Trino cluster.
Go to Managed Service for Trino.
Click Create cluster and set the cluster parameters.
Under Access settings, click .
In the Tables field, click Add rule.
In the window that opens, set the rule settings:
1. Optionally, provide a rule description in the Comment field.
2. Optionally, in the Users field, select the users the rule applies to:
  1. Click Add.
  2. Select the users from the list that opens. Use the search bar above the list to find particular users.
  3. To deselect a user selected by mistake, click that user again in the list.
  If no user is selected, the rule applies to all users.
3. Optionally, in the Groups field, select the user groups the rule applies to:
  1. Click Add.
  2. From the list that opens, select the groups. Use the search bar above the list to find particular groups.
  3. To delete a group selected by mistake, click it again in the list.
  If you select no groups, the rule applies to all user groups.
4. Optionally, in the Privileges field, select permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create VIEW and read table data.
  If you do not select any actions, the rule will prohibit all actions with tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
5. Optionally, in the Filter field, specify a boolean SQL expression for user access to table rows.
  
  The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
6. Optionally, in the Catalogs the rule applies to field, specify the catalogs the rule applies to:
  - Name: Select catalog names. You can only select catalogs added in Catalogs.
  - Name (regular expression): Enter a regular expression. The rule applies to the catalogs whose names match the regular expression.
  - Not specified: Rule applies to all catalogs in the cluster.
7. Optionally, in the Schemas the rule applies to field, specify the schemas the rule applies to:
  - Name: Select schema names.
  - Name (regular expression): Enter a regular expression. The rule applies to the schemas whose names match the regular expression.
  - Not specified: Rule applies to all schemas.
8. Optionally, in the Tables the rule applies to field, specify the tables the rule applies to:
  - Name: Select table names.
  - Name (regular expression): Enter a regular expression. The rule applies to the tables whose names match the regular expression.
  - Not specified: Rule applies to all tables.
9. Optionally, in the Column access field, add a list of rules restricting user access to table columns:
  1. Click Add column.
  2. Specify a column name.
  3. Set up access to the column: None to deny access or All to allow.
  4. Specify a mask.
    
    Note
    
    A mask is an SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If you specify no mask, the column will not be masked.
  5. Add other rules in a similar way if required.
  6. To delete a rule added by mistake, click in the line with this rule.
  If no rule is defined for the column, users will have unrestricted access.
Add other rules in a similar way if required.
To delete a rule added by mistake, click in the line with this rule.
Click Create.

If you do not have the Yandex Cloud CLI yet, install and initialize it.

The folder used by default is the one specified when creating the CLI profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id options.

To set table access rules:

Create a file named access_control.yaml and paste the following code into it:
```
tables:
  # Rule 1
  - privileges: [<list_of_privileges>]
    table:
      names:
        any: [<list_of_table_names>]
      name_regexp: <regular_expression>
    schema:
      names:
        any: [<list_of_schema_names>]
      name_regexp: <regular_expression>
    catalog:
      name_regexp: <regular_expression>
    columns:
      # Access rule for column 1
      - name: <column_name>
        access: <column_access>
        mask: <SQL_expression>
      # Access rule for column 2
      - <Access_settings_for_column_2>
      ...
      # Access rule for column N
      - <Access_settings_for_column_N>
    filter: <SQL_expression>           
    groups: [<list_of_group_IDs>]
    users: [<list_of_user_IDs>]
    description: <rule_description>
  # Rule 2
  - <Rule_2_parameters>
  ...
  # Rule N
  - <Rule_N_parameters>
```
Where:
- tables: List of table rules. All the rule parameters are optional: privileges, table, schema, catalog, columns, filter, groups, users, and description.
- privileges: List of permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create a VIEW with table data reads.
  If you do not specify the privileges parameter, the rule will prohibit any actions with the tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
- table: Tables the rule applies to. If you do not specify table, the rule applies to all tables.
  - names: List of table names.
  - name_regexp: Regular expression. The rule applies to the tables whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- schema: Schemas the rule applies to. If you do not specify schema, the rule applies to all schemas.
  - names: List of schema names.
  - name_regexp: Regular expression. The rule applies to the schemas whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- catalog: Cluster catalogs the rule applies to. If you do not specify catalog, the rule applies to all cluster catalogs.
  - name_regexp: Regular expression. The rule applies to the catalogs whose names match the regular expression.
- columns: List of rules restricting user access to table columns. Each rule contains the required Queuing Duration and Function Init Duration parameters, and the optional mask parameter.
  - name: Column name.
  - access: Access to the column:
    - ALL: Access allowed.
    - NONE: Access not allowed.
  - mask: SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If the mask parameter is not set or contains an empty string, the column will not be masked.
  If no rule is defined for the column, users will have unrestricted access.
- filter: Boolean SQL expression for user access to table rows. The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
- groups: List of group IDs the rule applies to. If you do not specify groups, the rule applies to all user groups.
- users: List of user IDs the rule applies to. If you do not specify users, the rule applies to all users.
- description: Rule description.
View the description of the CLI command for creating a cluster:
```
yc managed-trino cluster create --help
```

Run this command:

yc managed-trino cluster create \
  ...
  --access-control-from-file access_control.yaml

For available cluster parameters and their descriptions, see this guide.

Create a Terraform configuration file describing your infrastructure.
Add the yandex_trino_access_control resource with the tables rule list to the configuration file.
```
resource "yandex_trino_cluster" "<cluster_name>" {
  ...
}

resource "yandex_trino_catalog" "<catalog_1_name>" {
  ...
}

resource "yandex_trino_catalog" "<catalog_2_name>" {
  ...
}

...

resource "yandex_trino_catalog" "<catalog_N_name>" {
  ...
}

resource "yandex_trino_access_control" "trino_access_control" {
  ...
  cluster_id  = yandex_trino_cluster.<cluster_name>.id
  tables = [
    # Rule 1
    {
      privileges    = ["<list_of_privileges>"]
      table     = {
        names       = ["<list_of_table_names>"]
        name_regexp = "<regular_expression>"
      }
      schema        = {
        names       = ["<list_of_schema_names>"]
        name_regexp = "<regular_expression>"
      }
      catalog       = {
        ids         = [
          yandex_trino_catalog.<catalog_1_name>.id,
          yandex_trino_catalog.<catalog_2_name>.id,
          ... 
          yandex_trino_catalog.<catalog_N_name>.id
        ]
        name_regexp = "<regular_expression>"
      }
      columns       = [
        # Access rule for column 1
        {
          name      = "<column_name>"
          access    = "<column_access>"
          mask      = "<SQL_expression>"
        },
        # Access rule for column 2
        {
          ...
        },
        ...
        # Access rule for column N
        {
          ...
        }                       
      ]
      filter       = "<SQL_expression>"
      users         = ["<list_of_user_IDs>"]
      groups        = ["<list_of_group_IDs>"]
      description   = "<rule_description>"
    },
    # Rule 2
    {
      ... 
    },
    ...
    # Rule N
    {
      ... 
    }
  ]
  ...
}
```
Where:
- tables: List of table rule sections. All the rule parameters are optional: privileges, table, schema, catalog, columns, filter, groups, users, and description.
- privileges: List of permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create a VIEW with table data reads.
  If you do not specify the privileges parameter, the rule will prohibit any actions with the tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
- table: Tables the rule applies to. If you do not specify table, the rule applies to all tables.
  - names: List of table names.
  - name_regexp: Regular expression. The rule applies to the tables whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- schema: Schemas the rule applies to. If you do not specify schema, the rule applies to all schemas.
  - names: List of schema names.
  - name_regexp: Regular expression. The rule applies to the schemas whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- catalog: Cluster catalogs the rule applies to. If the catalog section is not specified, the rule applies to all cluster catalogs.
  - ids: List of catalog IDs. These catalogs must be created in the same manifest.
  - name_regexp: Regular expression. The rule applies to the catalogs whose names match the regular expression.
  You can specify either ids or name_regexp but not both.
- columns: List of rule sections restricting user access to table columns. Each rule contains the required Queuing Duration and Function Init Duration parameters, and the optional mask parameter.
  - name: Column name.
  - access: Access to the column:
    - ALL: Access allowed.
    - NONE: Access not allowed.
  - mask: SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If the mask parameter is not set or contains an empty string, the column will not be masked.
  If no rule is defined for the column, users will have unrestricted access.
- filter: Boolean SQL expression for user access to table rows. The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
- groups: List of group IDs the rule applies to. If you do not specify groups, the rule applies to all user groups.
- users: List of user IDs the rule applies to. If you do not specify users, the rule applies to all users.
- description: Rule description.
Make sure the settings are correct.
1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure.
2. Run this command:
```
terraform validate
```
  Terraform will show any errors found in your configuration files.
Confirm updating the resources.
1. Run this command to view the planned changes:
```
terraform plan
```
  If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources.
2. If everything looks correct, apply the changes:
  1. Run this command:
```
terraform apply
```
  2. Confirm updating the resources.
  3. Wait for the operation to complete.

For more information, see this Terraform provider guide.

Get an IAM token for API authentication and put it in an environment variable:
```
export IAM_TOKEN="<IAM_token>"
```
Clone the cloudapi repository:
```
cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
```
Below, we assume that the repository contents reside in the ~/cloudapi/ directory.
Create a file named body.json and paste the following code into it:
```
{
  <cluster_parameters>
  ...
  "trino": {
    "catalogs": [
      {
        "name": "catalog_1_name",
        ...
      },
      {
        "name": "catalog_2_name",
        ...
      },
      ...
      {
        "name": "catalog_N_name",
        ...
      }
    ]
    ...
    "access_control": {
      "tables": [
        {
          "privileges": [
            "<list_of_privileges>"
          ],
          "table": {
            "names": {
              "any": [
                "<list_of_table_names>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "schema": {
            "names": {
              "any": [
                "<list_of_schema_names>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "catalog": {
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "columns": [
            {
              "name": "<column_name>",
              "access": "<column_access>",
              "mask": "<SQL_expression>"
            },
            {
              <Access_rule_for_column_2>
            },
            ...
            {
              <Access_rule_for_column_N>
            }
          ],
          "filter": "<SQL_expression>",
          "users": [
            "<list_of_user_IDs>"
          ],
          "groups": [
            "<list_of_group_IDs>"
          ],
          "description": "<rule_description>"
        },
        {
          <Rule_2_section>
        },
        ...
        {
          <Rule_N_section>
        }
      ]
    }
  }
}
```
Where:
- access_control: Access rule configuration in the cluster.
- tables: List of table rule sections. All the rule parameters are optional: privileges, table, schema, catalog, columns, filter, groups, users, and description.
- privileges: List of permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create a VIEW with table data reads.
  If you do not specify the privileges parameter, the rule will prohibit any actions with the tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
- table: Tables the rule applies to. If the table section is not specified, the rule applies to all tables.
  - names: List of table names.
  - name_regexp: Regular expression. The rule applies to the tables whose names match the regular expression.
  The table section must contain either the nested names section or the name_regexp parameter.
- schema: Schemas the rule applies to. If the schema section is not specified, the rule applies to all schemas.
  - names: List of schema names.
  - name_regexp: Regular expression. The rule applies to the schemas whose names match the regular expression.
  The schema section must contain either the nested names section or the name_regexp parameter.
- catalog: Catalogs the rule applies to. If the catalog section is not specified, the rule applies to all cluster catalogs.
  - names: List of catalog names. You must create catalogs within the same ClusterService/Create call.
  - name_regexp: Regular expression. The rule applies to the catalogs whose names match the regular expression.
  The catalog section must contain either the nested names section or the name_regexp parameter.
- columns: List of rule sections restricting user access to table columns. Each rule contains the required Queuing Duration and Function Init Duration parameters, and the optional mask parameter.
  - name: Column name.
  - access: Access to the column:
    - ALL: Access allowed.
    - NONE: Access not allowed.
  - mask: SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If the mask parameter is not set or contains an empty string, the column will not be masked.
  If no rule is defined for the column, users will have unrestricted access.
- filter: Boolean SQL expression for user access to table rows. The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
- groups: List of group IDs the rule applies to. If you do not specify groups, the rule applies to all user groups.
- users: List of user IDs the rule applies to. If you do not specify users, the rule applies to all users.
- description: Rule description.
For available cluster parameters and their descriptions, see this guide.

Call the ClusterService/Create method, e.g., via the following gRPCurl request:

grpcurl \
    -format json \
    -import-path ~/cloudapi/ \
    -import-path ~/cloudapi/third_party/googleapis/ \
    -proto ~/cloudapi/yandex/cloud/trino/v1/cluster_service.proto \
    -rpc-header "Authorization: Bearer $IAM_TOKEN" \
    -d @ \
    trino.api.cloud.yandex.net:443 \
    yandex.cloud.trino.v1.ClusterService.Create \
    < body.json

Check the server response to make sure your request was successful.

Setting rules for an existing cluster

You can set or update table access rules for an existing Managed Service for Trino cluster.

Warning

Names of tables and schemas specified in rules are not validated. If a table name or a schema name contains an error, the rule will not apply correctly.

Management console

CLI

Terraform

gRPC API

In the management console, navigate to the relevant folder.
Go to Managed Service for Trino.
Click the name of your cluster.
Go to Access settings → Tables.
To add a rule, click Add rule. In the window that opens, set the rule settings:
1. Optionally, provide a rule description in the Comment field.
2. Optionally, in the Users field, select the users the rule applies to:
  1. Click Add.
  2. Select the users from the list that opens. Use the search bar above the list to find particular users.
  3. To deselect a user selected by mistake, click that user again in the list.
  If no user is selected, the rule applies to all users.
3. Optionally, in the Groups field, select the user groups the rule applies to:
  1. Click Add.
  2. From the list that opens, select the groups. Use the search bar above the list to find particular groups.
  3. To delete a group selected by mistake, click it again in the list.
  If you select no groups, the rule applies to all user groups.
4. Optionally, in the Privileges field, select permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create VIEW and read table data.
  If you do not select any actions, the rule will prohibit all actions with tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
5. Optionally, in the Filter field, specify a boolean SQL expression for user access to table rows.
  
  The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
6. Optionally, in the Catalogs the rule applies to field, specify the catalogs the rule applies to:
  - ID: Select catalog IDs. You can only select catalogs existing in the cluster.
  - Name: Select catalog names. You can only select catalogs existing in the cluster.
  - Name (regular expression): Enter a regular expression. The rule applies to the catalogs whose names match the regular expression.
  - Not specified: Rule applies to all catalogs in the cluster.
7. Optionally, in the Schemas the rule applies to field, specify the schemas the rule applies to:
  - Name: Select schema names.
  - Name (regular expression): Enter a regular expression. The rule applies to the schemas whose names match the regular expression.
  - Not specified: Rule applies to all schemas.
8. Optionally, in the Tables the rule applies to field, specify the tables the rule applies to:
  - Name: Select table names.
  - Name (regular expression): Enter a regular expression. The rule applies to the tables whose names match the regular expression.
  - Not specified: Rule applies to all tables.
9. Optionally, in the Column access field, add a list of rules restricting user access to table columns:
  1. Click Add column.
  2. Specify a column name.
  3. Set up access to the column: None to deny access or All to allow.
  4. Specify a mask.
    
    Note
    
    A mask is an SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If you specify no mask, the column will not be masked.
  5. Add other rules in a similar way if required.
  6. To delete a rule added by mistake, click in the line with this rule.
  If no rule is defined for the column, users will have unrestricted access.
Add other rules in a similar way if required.
To edit a rule:
1. Click in the line with this rule.
2. Update the rule settings and click Update.
To delete a rule you no longer need, click in the line with this rule.
Click Save changes.

If you do not have the Yandex Cloud CLI yet, install and initialize it.

To set table access rules:

If you have not set any access rules yet, create a file named access_control.yaml and paste the following into it:
```
tables:
  # Rule 1
  - privileges: [<list_of_privileges>]
    table:
      names:
        any: [<list_of_table_names>]
      name_regexp: <regular_expression>
    schema:
      names:
        any: [<list_of_schema_names>]
      name_regexp: <regular_expression>
    catalog:
      ids:
        any: [<list_of_catalog_IDs>]
      names:
        any: [<list_of_catalog_names>]
      name_regexp: <regular_expression>
    columns:
      # Access rule for column 1
      - name: <column_name>
        access: <column_access>
        mask: <SQL_expression>
      # Access rule for column 2
      - <Access_settings_for_column_2>
      ...
      # Access rule for column N
      - <Access_settings_for_column_N>
    filter: <SQL_expression>           
    groups: [<list_of_group_IDs>]
    users: [<list_of_user_IDs>]
    description: <rule_description>
  # Rule 2
  - <Rule_2_parameters>
  ...
  # Rule N
  - <Rule_N_parameters>
```
Where:
- tables: List of table rules. All the rule parameters are optional: privileges, table, schema, catalog, columns, filter, groups, users, and description.
- privileges: List of permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create a VIEW with table data reads.
  If you do not specify the privileges parameter, the rule will prohibit any actions with the tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
- table: Tables the rule applies to. If you do not specify table, the rule applies to all tables.
  - names: List of table names.
  - name_regexp: Regular expression. The rule applies to the tables whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- schema: Schemas the rule applies to. If you do not specify schema, the rule applies to all schemas.
  - names: List of schema names.
  - name_regexp: Regular expression. The rule applies to the schemas whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- catalog: Catalogs the rule applies to. If you do not specify catalog, the rule applies to all cluster catalogs.
  - ids: List of catalog IDs. These must be the existing catalogs.
  - names: List of catalog names. These must be the existing catalogs.
  - name_regexp: Regular expression. The rule applies to the catalogs whose names match the regular expression.
  You can specify only one of the following: ids, names, or name_regexp.
- columns: List of rules restricting user access to table columns. Each rule contains the required Queuing Duration and Function Init Duration parameters, and the optional mask parameter.
  - name: Column name.
  - access: Access to the column:
    - ALL: Access allowed.
    - NONE: Access not allowed.
  - mask: SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If the mask parameter is not set or contains an empty string, the column will not be masked.
  If no rule is defined for the column, users will have unrestricted access.
- filter: Boolean SQL expression for user access to table rows. The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
- groups: List of group IDs the rule applies to. If you do not specify groups, the rule applies to all user groups.
- users: List of user IDs the rule applies to. If you do not specify users, the rule applies to all users.
- description: Rule description.
If you have already set the access rules, open access_control.yaml and edit it as needed. You can:
- Add new rules.
- Update the existing ones.
- Delete the rules you no longer need.

Run this command:

yc managed-trino cluster set-access-control <cluster_name_or_ID> \
  --from-file access_control.yaml

You can get the cluster ID and name with the list of clusters in the folder.

Open the current Terraform configuration file describing your infrastructure.

To learn how to create this file, see Creating a cluster.
If you have not set any access rules yet, add the yandex_trino_access_control resource containing the tables rule list.
```
resource "yandex_trino_cluster" "<cluster_name>" {
  ...
}

resource "yandex_trino_catalog" "<catalog_1_name>" {
  ...
}

resource "yandex_trino_catalog" "<catalog_2_name>" {
  ...
}

...

resource "yandex_trino_catalog" "<catalog_N_name>" {
  ...
}

resource "yandex_trino_access_control" "trino_access_control" {
  ...
  cluster_id  = yandex_trino_cluster.<cluster_name>.id
  tables = [
    # Rule 1
    {
      privileges    = ["<list_of_privileges>"]
      table     = {
        names       = ["<list_of_table_names>"]
        name_regexp = "<regular_expression>"
      }
      schema        = {
        names       = ["<list_of_schema_names>"]
        name_regexp = "<regular_expression>"
      }
      catalog       = {
        ids         = [
          yandex_trino_catalog.<catalog_1_name>.id,
          yandex_trino_catalog.<catalog_2_name>.id,
          ... 
          yandex_trino_catalog.<catalog_N_name>.id
        ]
        name_regexp = "<regular_expression>"
      }
      columns       = [
        # Access rule for column 1
        {
          name      = "<column_name>"
          access    = "<column_access>"
          mask      = "<SQL_expression>"
        },
        # Access rule for column 2
        {
          ...
        },
        ...
        # Access rule for column N
        {
          ...
        }                       
      ]
      filter       = "<SQL_expression>"
      users         = ["<list_of_user_IDs>"]
      groups        = ["<list_of_group_IDs>"]
      description   = "<rule_description>"
    },
    # Rule 2
    {
      ... 
    },
    ...
    # Rule N
    {
      ... 
    }
  ]
  ...
}
```
Where:
- tables: List of table rule sections. All the rule parameters are optional: privileges, table, schema, catalog, columns, filter, groups, users, and description.
- privileges: List of permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create a VIEW with table data reads.
  If you do not specify the privileges parameter, the rule will prohibit any actions with the tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
- table: Tables the rule applies to. If you do not specify table, the rule applies to all tables.
  - names: List of table names.
  - name_regexp: Regular expression. The rule applies to the tables whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- schema: Schemas the rule applies to. If you do not specify schema, the rule applies to all schemas.
  - names: List of schema names.
  - name_regexp: Regular expression. The rule applies to the schemas whose names match the regular expression.
  You can specify either names or name_regexp but not both.
- catalog: Cluster catalogs the rule applies to. If the catalog section is not specified, the rule applies to all cluster catalogs.
  - ids: List of catalog IDs. These must exist or be created in the same manifest.
  - name_regexp: Regular expression. The rule applies to the catalogs whose names match the regular expression.
  You can specify either ids or name_regexp but not both.
- columns: List of rule sections restricting user access to table columns. Each rule contains the required Queuing Duration and Function Init Duration parameters, and the optional mask parameter.
  - name: Column name.
  - access: Access to the column:
    - ALL: Access allowed.
    - NONE: Access not allowed.
  - mask: SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If the mask parameter is not set or contains an empty string, the column will not be masked.
  If no rule is defined for the column, users will have unrestricted access.
- filter: Boolean SQL expression for user access to table rows. The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
- groups: List of group IDs the rule applies to. If you do not specify groups, the rule applies to all user groups.
- users: List of user IDs the rule applies to. If you do not specify users, the rule applies to all users.
- description: Rule description.
If you have already set the access rules, edit the yandex_trino_access_control resource description. You can:
- Add new rules.
- Update the existing ones.
- Delete the rules you no longer need.
Make sure the settings are correct.
1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure.
2. Run this command:
```
terraform validate
```
  Terraform will show any errors found in your configuration files.
Confirm updating the resources.
1. Run this command to view the planned changes:
```
terraform plan
```
  If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources.
2. If everything looks correct, apply the changes:
  1. Run this command:
```
terraform apply
```
  2. Confirm updating the resources.
  3. Wait for the operation to complete.

For more information, see this Terraform provider guide.

Get an IAM token for API authentication and place it in an environment variable:
```
export IAM_TOKEN="<IAM_token>"
```
Clone the cloudapi repository:
```
cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
```
Below, we assume that the repository contents reside in the ~/cloudapi/ directory.
If you have not set any access rules yet, create a file named body.json and paste the following code into it:
```
{
  "cluster_id": "<cluster_ID>",
  "update_mask": {
    "paths": [
      "trino.access_control.tables"
    ]
  },
  "trino": {
    "access_control": {
      "tables": [
        {
          "privileges": [
            "<list_of_privileges>"
          ],
          "table": {
            "names": {
              "any": [
                "<list_of_table_names>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "schema": {
            "names": {
              "any": [
                "<list_of_schema_names>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "catalog": {
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "columns": [
            {
              "name": "<column_name>",
              "access": "<column_access>",
              "mask": "<SQL_expression>"
            },
            {
              <Access_rule_for_column_2>
            },
            ...
            {
              <Access_rule_for_column_N>
            }
          ],
          "filter": "<SQL_expression>",
          "users": [
            "<list_of_user_IDs>"
          ],
          "groups": [
            "<list_of_group_IDs>"
          ],
          "description": "<rule_description>"
        },
        {
          <Rule_2_section>
        },
        ...
        {
          <Rule_N_section>
        }
      ]
    }
  }
}
```
Where:
- cluster_id: Cluster ID.
  
  You can get the cluster ID with the list of clusters in the folder.
- update_mask: List of parameters to update as an array of strings (paths[]).
  Format for listing settings
  "update_mask": { "paths": [ "<setting_1>", "<setting_2>", ... "<setting_N>" ] }
  Warning
  
  When you update a cluster, all parameters of the object you are modifying will take their defaults unless explicitly provided in the request. To avoid this, list the settings you want to change in the update_mask parameter.
- access_control: Access rule configuration in the cluster.
- tables: List of table rule sections. All the rule parameters are optional: privileges, table, schema, catalog, columns, filter, groups, users, and description.
- privileges: List of permitted actions with tables:
  - SELECT: Read data.
  - INSERT: Insert data.
  - DELETE: Delete data.
  - UPDATE: Update data.
  - OWNERSHIP: Create and delete a table, change columns, and add comments to a table.
  - GRANT_SELECT: Create a VIEW with table data reads.
  If you do not specify the privileges parameter, the rule will prohibit any actions with the tables.
  
  Note
  
  To use the OWNERSHIP privilege for the table, you need the ALL access level for the catalog containing that table.
- table: Tables the rule applies to. If the table section is not specified, the rule applies to all tables.
  - names: List of table names.
  - name_regexp: Regular expression. The rule applies to the tables whose names match the regular expression.
  The table section must contain either the nested names section or the name_regexp parameter.
- schema: Schemas the rule applies to. If the schema section is not specified, the rule applies to all schemas.
  - names: List of schema names.
  - name_regexp: Regular expression. The rule applies to the schemas whose names match the regular expression.
  The schema section must contain either the nested names section or the name_regexp parameter.
- catalog: Catalogs the rule applies to. If the catalog section is not specified, the rule applies to all cluster catalogs.
  - ids: List of catalog IDs. These must be the existing catalogs.
  - names: List of catalog names. These must be the existing catalogs.
  - name_regexp: Regular expression. The rule applies to the catalogs whose names match the regular expression.
  The catalog section must contain either one of the nested ids or names sections, or the name_regexp parameter.
- columns: List of rule sections restricting user access to table columns. Each rule contains the required Queuing Duration and Function Init Duration parameters, and the optional mask parameter.
  - name: Column name.
  - access: Access to the column:
    - ALL: Access allowed.
    - NONE: Access not allowed.
  - mask: SQL expression to mask the column. When reading, user will get the expression result instead of this column's value. The SQL expression type must match the type of the masked column. If the mask parameter is not set or contains an empty string, the column will not be masked.
  If no rule is defined for the column, users will have unrestricted access.
- filter: Boolean SQL expression for user access to table rows. The user will only have access to the row if the expression returns TRUE. The SQL expression is calculated on behalf of the user who runs the query. If the filter parameter is not specified or contains an empty string, users will have access to all table rows.
- groups: List of group IDs the rule applies to. If you do not specify groups, the rule applies to all user groups.
- users: List of user IDs the rule applies to. If you do not specify users, the rule applies to all users.
- description: Rule description.
If you have already set the access rules, open the existing body.json rules file and edit it as needed. You can:
- Add new rules.
- Update the existing ones.
- Delete the rules you no longer need.

Call the ClusterService.Update method, e.g., via the following gRPCurl request:

grpcurl \
  -format json \
  -import-path ~/cloudapi/ \
  -import-path ~/cloudapi/third_party/googleapis/ \
  -proto ~/cloudapi/yandex/cloud/trino/v1/cluster_service.proto \
  -rpc-header "Authorization: Bearer $IAM_TOKEN" \
  -d @ \
  trino.api.cloud.yandex.net:443 \
  yandex.cloud.trino.v1.ClusterService.Update \
  < body.json

Check the server response to make sure your request was successful.

Example of setting table access rules

Let’s configure access rules for tables in a Trino cluster:

Prohibit any actions with tables to the user with the banned_user_id ID.
Allow any actions with tables to the user group with the admins_group_id ID.
Allow reading data from the sales and orders tables to all users, in which case:
- A user can only access a table row if the manager_id column value matches the current user ID.
- The client_phone column value will be masked with ***, except for the last four digits.
Prohibit any actions with tables to all other users.

CLI

Terraform

gRPC API

The access_control.yaml file for this rule set is as follows:

tables:
  - users:
      - banned_user_id

  - groups:
      - admins_group_id
    privileges:
      - SELECT
      - INSERT
      - DELETE
      - UPDATE
      - OWNERSHIP
      - GRANT_SELECT

  - table:
      names:
        any:
          - sales
          - orders
    columns:
      - name: client_phone
        access: ALL
        mask: "'***' || substring(client_phone, -4)"
    filter: "manager_id = current_user"
    privileges:
      - SELECT

The configuration file for this rule set is as follows:

resource "yandex_trino_access_control" "trino_access_control" {
  ...
  cluster_id  = <cluster_ID>
  tables = [
    {
      users         = ["banned_user_id"]
    },
    {
      groups        = ["admins_group_id"]
      privileges    = ["SELECT", "INSERT", "DELETE", "UPDATE", "OWNERSHIP", "GRANT_SELECT"]
    },
    {
      table         = {
        names       = ["sales", "orders"]
      }
      columns       = [
        {
          name      = "client_phone"
          access    = "ALL"
          mask      = "'***' || substring(client_phone, -4)"
        }
      ]
      filter        = "manager_id = current_user"
      privileges    = ["SELECT"]
    }
  ]
  ...
}

The body.json file for this rule set is as follows:

{
  "cluster_id": "<cluster_ID>",
  "update_mask": {
    "paths": [
      "trino.access_control.tables"
    ]
  },
  "trino": {
    "access_control": {
      "tables": [
        {
          "users": [
            "banned_user_id"
          ]
        },
        {
          "groups": [
            "admins_group_id"
          ],
          "privileges": [
            "SELECT",
            "INSERT",
            "DELETE",
            "UPDATE",
            "OWNERSHIP",
            "GRANT_SELECT"
          ]
        },
        {
          "table": {
            "names": {
              "any": [
                "orders",
                "sales"
              ]
            }
          },
          "columns": [
            {
              "name": "client_phone",
              "access": "ALL",
              "mask": "'***' || substring(client_phone, -4)"
            }
          ],            
          "filter": "manager_id = current_user",
          "privileges": [
            "SELECT"
          ]
        }
      ]
    }
  }
}

Assigning access rules for tables in Managed Service for Trino

Setting rules when creating a clusterSetting rules when creating a cluster

Setting rules for an existing clusterSetting rules for an existing cluster

Example of setting table access rulesExample of setting table access rules

Was the article helpful?

Setting rules when creating a cluster

Setting rules for an existing cluster

Example of setting table access rules