Contact UsTry it for free
© 2026 Direct Cursus Technology L.L.C.

Assigning access rules for catalog objects in Managed Service for Trino

Written by
Updated at March 17, 2026

Catalog object access rules enable you to restrict user access to all objects in one or more catalogs within a Managed Service for Trino cluster. To manage access to individual cluster objects, use more granular rules, e.g., access rules for schemas or tables.

For each user-object pair, the access rules apply as follows:

  • Rules are checked for matches in the order they are listed in the configuration file. The first rule matching the user-object pair applies.
  • If none of the rules match the user-object pair, access is denied.
  • If no rules are defined for catalogs, user access to catalog objects is controlled by more granular rules, e.g., table rules.

Setting rules when creating a cluster

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

  1. In the management console, select the folder where you want to create a Managed Service for Trino cluster.

  2. Go to Managed Service for Trino.

  3. Click Create cluster and set the cluster parameters.

  4. Under Access settings, click .

  5. In the Catalogs field, click Add rule.

  6. 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. In the Permissions field, select the access level for folder objects:

      • NONE: All operations on catalog objects are prohibited.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.

    5. 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. Add other rules in a similar way if required.

  8. To delete a rule added by mistake, click in the line with this rule.

  9. 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 access rules for catalog objects:

  1. Create a file named access_control.yaml and paste the following code into it:

    catalogs:
  # Rule 1
  - permission: <access_level>
    catalog:
      name_regexp: <regular_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:

    • catalogs: List of catalog rules. Each rule contains the required permission parameter as well as optional parameters: catalog, groups, users, and description.

    • permission: User or group access level to catalogs assigned by the rule:

      • NONE: All operations on catalog objects are prohibited.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.

    • 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.

    • 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.

  2. View the description of the CLI command for creating a cluster:

    yc managed-trino cluster create --help

  3. 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.

  1. Create a Terraform configuration file describing your infrastructure.

  2. Add the yandex_trino_access_control resource with the catalogs 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
  catalogs = [
    # Rule 1
    {
      permission    = "<access_level>"
      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>"
      }
      users         = ["<list_of_user_IDs>"]
      groups        = ["<list_of_group_IDs>"]
      description   = "<rule_description>"
    },
    # Rule 2
    {
      ... 
    },
    ...
    # Rule N
    {
      ... 
    }
  ]
  ...
}

    Where:

    • catalogs: List of catalog rule sections. Each rule contains the required permission parameter as well as optional parameters: catalog, groups, users, and description.

    • permission: User or group access level to catalogs assigned by the rule:

      • NONE: All operations on catalog objects are prohibited.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.

    • 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 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.

    • 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.

  3. 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.

  4. 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.

  1. Get an IAM token for API authentication and put it in an environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. 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.

  3. 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": {
      "catalogs": [
        {
          "permission": "<access_level>",
          "catalog": {
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "name_regexp": "<regular_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.

    • catalogs: List of catalog rule sections. Each rule contains the required permission parameter as well as optional parameters: catalog, groups, users, and description.

    • permission: User or group access level to catalogs assigned by the rule:

      • NONE: All operations on catalog objects are prohibited.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.

    • 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.

    • 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.

  4. 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

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

Setting rules for an existing cluster

You can set or update access rules for catalog objects in an existing Managed Service for Trino cluster.

  1. In the management console, navigate to the relevant folder.

  2. Go to Managed Service for Trino.

  3. Click the name of your cluster.

  4. Go to Access settings → Catalogs.

  5. 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. In the Permissions field, select the access level for folder objects:

      • NONE: All operations on catalog objects are prohibited.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.

    5. 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.

  6. Add other rules in a similar way if required.

  7. To edit a rule:

    1. Click in the line with this rule.
    2. Update the rule settings and click Update.

  8. To delete a rule you no longer need, Click in the line with this rule.

  9. Click Save changes.

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 access rules for catalog objects:

  1. If you have not set any access rules yet, create a file named access_control.yaml and paste the following into it:

    catalogs:
  # Rule 1
  - permission: <access_level>
    catalog:
      ids:
        any: [<list_of_catalog_IDs>]
      names:
        any: [<list_of_catalog_names>]
      name_regexp: <regular_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:

    • catalogs: List of catalog rules. Each rule contains the required permission parameter as well as optional parameters: catalog, groups, users, and description.

    • permission: User or group access level to catalogs assigned by the rule:

      • NONE: All operations on catalog objects are prohibited.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.

    • 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.

    • 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.

  2. 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.

  3. 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.

  1. Open the current Terraform configuration file describing your infrastructure.

    To learn how to create this file, see Creating a cluster.

  2. If you have not set any access rules yet, add the yandex_trino_access_control resource containing the catalogs 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
  catalogs = [
    # Rule 1
    {
      permission    = "<access_level>"
      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>"
      }
      users         = ["<list_of_user_IDs>"]
      groups        = ["<list_of_group_IDs>"]
      description   = "<rule_description>"
    },
    # Rule 2
    {
      ... 
    },
    ...
    # Rule N
    {
      ... 
    }
  ]
  ...
}

    Where:

    • catalogs: List of catalog rule sections. Each rule contains the required permission parameter as well as optional parameters: catalog, groups, users, and description.

    • permission: User or group access level to catalogs assigned by the rule:

      • NONE: All operations on catalog objects are prohibited.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.

    • 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 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.

    • 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.

  3. 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.

  4. 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.

  5. 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.

  1. Get an IAM token for API authentication and place it in an environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. 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.

  3. 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.catalogs"
    ]
  },
  "trino": {
    "access_control": {
      "catalogs": [
        {
          "permission": "<access_level>",
          "catalog": {
            "name_regexp": "<regular_expression>",
            "ids": {
              "any": [
                "<list_of_catalog_IDs>"
              ]
            },
            "names": {
              "any": [
                "<list_of_catalog_names>"
              ]
            }
          },
          "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.

    • catalogs: List of catalog rule sections. Each rule contains the required permission parameter as well as optional parameters: catalog, groups, users, and description.

    • permission: User or group access level to catalogs assigned by the rule:

      • NONE: All operations on catalog objects are prohibited.
      • READ_ONLY: Only read operations are allowed, e.g., reading data from a table.
      • ALL: All operations are allowed. In which case user access to catalog objects is controlled by more granular rules, e.g., table rules.

    • 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 and names sections or the name_regexp parameter.

    • 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.

  4. If you have already set the rules, open the relevant body.json file and edit it as needed. You can:

    • Add new rules.
    • Update the existing ones.
    • Delete the rules you no longer need.

  5. 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

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

Example of setting access rules for catalog objects

Let's configure access rules for objects in Trino cluster catalogs:

  1. Deny any actions on objects in all cluster catalogs to users from the group with the banned_group_id.
  2. Allow all operations with objects in catalogs with the cat1_id and cat2_id to users with the user1_id and user2_id if they belong to the group with the analytics_group_id.
  3. Allow all users to read objects in catalogs with names that match the .*_prod regular expression.

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

catalogs:
  - permission: NONE
    groups:
      - banned_group_id

  - permission: ALL
    catalog:
      ids:
        any:
          - cat1_id
          - cat2_id
    groups:
      - analytics_group_id
    users:
      - user1_id
      - user2_id

  - permission: READ_ONLY
    catalog:
      name_regexp: ".*_prod"

The configuration file for this rule set is as follows:

resource "yandex_trino_access_control" "trino_access_control" {
  ...
  cluster_id  = <cluster_ID>
  catalogs = [
    {
      permission    = "NONE"
      groups        = ["banned_group_id"]
    },
    {
      permission    = "ALL"
      catalog       = {
        ids         = ["cat1_id", "cat2_id"]
      }
      users         = ["user1_id", "user2_id"]
      groups        = ["analytics_group_id"]
    },
    {
      permission    = "READ_ONLY"
      catalog       = {
        name_regexp = ".*_prod"
      }
    }
  ]
  ...
}

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

{
  "cluster_id": "<cluster_ID>",
  "update_mask": {
    "paths": [
      "trino.access_control.catalogs"
    ]
  },
  "trino": {
    "access_control": {
      "catalogs": [
        {
          "permission": "NONE",
          "groups": [
            "banned_group_id"
          ]
        },
        {
          "permission": "ALL",
          "catalog": {
            "ids": {
              "any": [
                "cat1_id",
                "cat2_id"
              ]
            }
          },
          "users": [
            "user1_id",
            "user2_id"
          ],
          "groups": [
            "analytics_group_id"
          ]
        },
        {
          "permission": "READ_ONLY",
          "catalog": {
            "name_regexp": ".*_prod"
          }
        }
      ]
    }
  }
}
Previous
Getting access rules
Next
Assigning rules for schemas