Discuss with expertTry it for free
© 2026 Direct Cursus Technology L.L.C.

Assigning access rules for functions in Managed Service for Trino

Written by
Updated at June 15, 2026

Access rules define the actions users can perform with custom functions in a Managed Service for Trino cluster.

Note

You cannot restrict the execution of functions residing in the system.builtin virtual schema, i.e., the built-in Trino functions.

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

  • Rules are checked in the order of their declaration. The first rule matching the user-function pair applies.
  • If none of the rules match the user-function pair, the user is denied all actions with the function.
  • If no function access rules are set, only the built-in functions are allowed for each user.
  • Function access rules apply together with the top-level rules for objects in catalogs.

Setting rules when creating a cluster

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

Warning

Function and schema names specified in the rules are not validated. If a function name or a schema name contains an error, the rule will not apply correctly.

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

  2. Navigate to Managed Service for Trino.

  3. Click Create cluster and set the cluster parameters.

  4. Under Access settings, click .

  5. In the Functions field, click Add rule.

  6. In the window that opens, set up the rule:

    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 functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not select any actions, the rule will prohibit any actions with functions.

      Note

      To use the OWNERSHIP privilege for a function, you need the ALL access level for the catalog containing that function.

    5. Optionally, specify full names of the functions the rule will apply to, formatted as <catalog_name>.<schema_name>.<function_name>. Use a separate field for each part of the name.

      1. Select format for the catalogs:

        • Name: Select catalog names. You can only select catalogs added in Catalogs.
        • Name (regular expression): Enter a regular expression for catalog names.
        • Not specified: The <catalog_name> field may contain any value.

      2. Select format for the schemas:

        • Name: Select schema names.
        • Name (regular expression): Enter a regular expression for schema names.
        • Not specified: The <schema_name> field may contain any value.

      3. Select format for the functions:

        • Name: Select function names.
        • Name (regular expression): Enter a regular expression for function names.
        • Not specified: The <function_name> field may contain any value.

  7. Add other rules in the same way as needed.

  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 specify a different folder for any command using --folder-name or --folder-id. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

To set function access rules:

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

    functions:
  # Rule 1
  - privileges: [<list_of_privileges>]
    catalog:
      name_regexp: <regular_expression>
    schema:
      names:
        any: [<list_of_schema_names>]
      name_regexp: <regular_expression>
    function:
      names:
        any: [<list_of_function_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:

    • functions: List of function rules. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs set using the name_regexp parameter (regular expression for catalog names).

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • Name (regular expression): Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • Name (regular expression): Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply 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 functions 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
  functions = [
    # Rule 1
    {
      privileges    = ["<list_of_privileges>"]
      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>"
      }
      schema        = {
        names       = ["<list_of_schema_names>"]
        name_regexp = "<regular_expression>"
      }
      function      = {
        names       = ["<list_of_function_names>"]
        name_regexp = "<regular_expression>"
      }
      users         = ["<list_of_user_IDs>"]
      groups        = ["<list_of_group_IDs>"]
      description   = "<rule_description>"
    },
    # Rule 2
    {
      ... 
    },
    ...
    # Rule N
    {
      ... 
    }
  ]
  ...
}

    Where:

    • functions: List of function rule sections. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • ids: List of catalog IDs. These catalogs must be created in the same manifest.
        • name_regexp: Regular expression for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • Name (regular expression): Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • Name (regular expression): Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply 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 into an environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. 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",
        ...
      }
    ]
    ...
    "accessControl": {
      "functions": [
        {
          "privileges": [
            "<list_of_privileges>"
          ],
          "catalog": {
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "nameRegexp": "<regular_expression>"
          },
          "schema": {
            "names": {
              "any": [
                "<list_of_schema_names>"
              ]
            },
            "nameRegexp": "<regular_expression>"
          },
          "function": {
            "names": {
              "any": [
                "<list_of_function_names>"
              ]
            },
            "nameRegexp": "<regular_expression>"
          },
          "users": [
            "<list_of_user_IDs>"
          ],
          "groups": [
            "<list_of_group_IDs>"
          ],
          "description": "<rule_description>"
        },
        {
          <Rule_2_section>
        },
        ...
        {
          <Rule_N_section>
        }
      ]
    }
  }
}

    Where:

    • accessControl: Access rule configuration in the cluster.

    • functions: List of function rule sections. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • names: List of catalog names. You must create catalogs within the same Cluster.Create call.
        • nameRegexp: Regular expression for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • nameRegexp: Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • nameRegexp: Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply to all users.

    • description: Rule description.

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

  3. Call the Cluster.Create method, e.g., via the following cURL request:

    curl \
    --request POST \
    --header "Authorization: Bearer $IAM_TOKEN" \
    --url 'https://trino.api.cloud.yandex.net/managed-trino/v1/clusters'
    --data '@body.json'

  4. View the server response to make sure your request was successful.

  1. Get an IAM token for API authentication and put it into 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": {
      "functions": [
        {
          "privileges": [
            "<list_of_privileges>"
          ],
          "catalog": {
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "schema": {
            "names": {
              "any": [
                "<list_of_schema_names>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "function": {
            "names": {
              "any": [
                "<list_of_function_names>"
              ]
            },
            "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.

    • functions: List of function rule sections. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • names: List of catalog names. You must create catalogs within the same ClusterService/Create call.
        • name_regexp: Regular expression for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • Name (regular expression): Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • Name (regular expression): Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply 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 function access rules for an existing Managed Service for Trino cluster.

Warning

Function and schema names specified in the rules are not validated. If a function name or a schema name contains an error, the rule will not apply correctly.

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

  2. Navigate to Managed Service for Trino.

  3. Click the cluster name.

  4. Go to Access settings → Functions.

  5. To add a rule, click Add rule. In the window that opens, set up the rule:

    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 functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not select any actions, the rule will prohibit any actions with functions.

      Note

      To use the OWNERSHIP privilege for a function, you need the ALL access level for the catalog containing that function.

    5. Optionally, specify full names of the functions the rule will apply to, formatted as <catalog_name>.<schema_name>.<function_name>. Use a separate field for each part of the name.

      1. Select format for the catalogs:

        • ID: Select catalog IDs. You can only select catalogs from those present in the cluster.
        • Name: Select catalog names. You can only select catalogs existing in the cluster.
        • Name (regular expression): Enter a regular expression for catalog names.
        • Not specified: The <catalog> field may contain any value.

      2. Select format for the schemas:

        • Name: Select schema names.
        • Name (regular expression): Enter a regular expression for schema names.
        • Not specified: The <schema_name> field may contain any value.

      3. Select format for the functions:

        • Name: Select function names.
        • Name (regular expression): Enter a regular expression for function names.
        • Not specified: The <function_name> field may contain any value.

  6. Add other rules in the same way as needed.

  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 specify a different folder for any command using --folder-name or --folder-id. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

To set function access rules:

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

    functions:
  # Rule 1
  - privileges: [<list_of_privileges>]
    catalog:
      ids:
        any: [<list_of_catalog_IDs>]
      names:
        any: [<list_of_catalog_names>]
      name_regexp: <regular_expression>
    schema:
      names:
        any: [<list_of_schema_names>]
      name_regexp: <regular_expression>
    function:
      names:
        any: [<list_of_function_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:

    • functions: List of function rules. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • 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 for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • Name (regular expression): Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • Name (regular expression): Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply 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.

    For more on 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 functions 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
  functions = [
    # Rule 1
    {
      privileges    = ["<list_of_privileges>"]
      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>"
      }
      schema        = {
        names       = ["<list_of_schema_names>"]
        name_regexp = "<regular_expression>"
      }
      function     = {
        names       = ["<list_of_function_names>"]
        name_regexp = "<regular_expression>"
      }
      users         = ["<list_of_user_IDs>"]
      groups        = ["<list_of_group_IDs>"]
      description   = "<rule_description>"
    },
    # Rule 2
    {
      ... 
    },
    ...
    # Rule N
    {
      ... 
    }
  ]
  ...
}

    Where:

    • functions: List of function rule sections. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • ids: List of catalog IDs. These must exist or be created in the same manifest.
        • name_regexp: Regular expression for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • Name (regular expression): Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • Name (regular expression): Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply 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 put it into an environment variable:

    export IAM_TOKEN="<IAM_token>"

  2. If you have not set any access rules yet, create a file named body.json and paste the following code into it:

    {
  "updateMask": "trino.accessControl.functions",
  "trino": {
    "accessControl": {
      "functions": [
        {
          "privileges": [
            "<list_of_privileges>"
          ],
          "catalog": {
            "ids": {
              "any": [
                "<list_of_catalog_IDs>"
              ]
            },
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "nameRegexp": "<regular_expression>"
          },
          "schema": {
            "names": {
              "any": [
                "<list_of_schema_names>"
              ]
            },
            "nameRegexp": "<regular_expression>"
          },
          "function": {
            "names": {
              "any": [
                "<list_of_function_names>"
              ]
            },
            "nameRegexp": "<regular_expression>"
          },
          "users": [
            "<list_of_user_IDs>"
          ],
          "groups": [
            "<list_of_group_IDs>"
          ],
          "description": "<rule_description>"
        },
        {
          <Rule_2_section>
        },
        ...
        {
          <Rule_N_section>
        }
      ]
    }
  }
}

    Where:

    • updateMask: Comma-separated list of parameters to update.

      Warning

      When you update a cluster, all parameters of the object you are modifying will be reset to their defaults unless explicitly provided in the request. To avoid this, list the settings you want to change in the updateMask parameter.

    • accessControl: Access rule configuration in the cluster.

    • functions: List of function rule sections. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • ids: List of catalog IDs. These must be the existing catalogs.
        • names: List of catalog names. These must be the existing catalogs.
        • nameRegexp: Regular expression for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • nameRegexp: Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • nameRegexp: Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply to all users.

    • description: Rule description.

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

  4. Call the Cluster.Update method, e.g., via the following cURL request:

    curl \
  --request PATCH \
  --header "Authorization: Bearer $IAM_TOKEN" \
  --url 'https://trino.api.cloud.yandex.net/managed-trino/v1/clusters/<cluster_ID>'
  --data '@body.json'

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

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

  1. Get an IAM token for API authentication and put it into 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.functions"
    ]
  },
  "trino": {
    "access_control": {
      "functions": [
        {
          "privileges": [
            "<list_of_privileges>"
          ],
          "catalog": {
            "ids": {
              "any": [
                "<list_of_catalog_IDs>"
              ]
            },
            "names": {
              "any": [
                "<catalog_1_name>",
                "<catalog_2_name>",
                ...
                "<catalog_N_name>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "schema": {
            "names": {
              "any": [
                "<list_of_schema_names>"
              ]
            },
            "name_regexp": "<regular_expression>"
          },
          "function": {
            "names": {
              "any": [
                "<list_of_function_names>"
              ]
            },
            "name_regexp": "<regular_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 be reset to 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.

    • functions: List of function rule sections. All the rule parameters are optional: privileges, catalog, schema, function, groups, users, and description.

    • privileges: List of permitted actions with functions:

      • EXECUTE: Calling a function.
      • GRANT_EXECUTE: Calling a function to create VIEW.
      • OWNERSHIP: Creating and deleting a function.

      If you do not specify the privileges parameter, the rule will prohibit any actions with the functions.

      Note

      To use the OWNERSHIP privilege for the function, you need the ALL access level for the catalog containing that function.

    • Combined, catalog, schema, and function define the functions the rule will apply to. Each of them is optional.

      • catalog: Catalogs specified by one of the following:

        • 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 for catalog names.

        Omitting the catalog section is equivalent to using the .* regular expression.

      • schema: Schemas specified by one of the following:

        • names: List of schema names.
        • Name (regular expression): Regular expression for schema names.

        Omitting the schema section is equivalent to using the .* regular expression.

      • function: Functions specified by one of the following:

        • names: List of function names.
        • Name (regular expression): Regular expression for function names.

        Omitting the function section is equivalent to using the .* regular expression.

      Note

      In Managed Service for Trino, full function name follows this template: <catalog_name>.<schema_name>.<function_name>. The rule applies to a function only if its full name is consistent with all the specified parameters.

    • The users and groups parameters define users the rule applies to.

      • users: List of user IDs. The rule will only apply to the specified users.

      • groups: List of group IDs. The rule will only apply to users who belong to at least one of these groups.

      You can specify either one or both parameters. If you specify both, the rule will apply to all users from the users parameter who also belong to at least one group listed under groups. If neither parameter is provided, the rule will apply to all users.

    • description: Rule description.

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

  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 function access rules

Let's configure access rules for custom functions in a Trino cluster:

  1. Prohibit any actions with functions to the user with the banned_user_id ID.
  2. Allow users in the group with the admins_group_id to create and delete any functions, and also call them to create a VIEW.
  3. Allow all other users to call functions with the .*_public name format.

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

functions:
  - users:
      - banned_user_id

  - groups:
      - admins_group_id
    privileges:
      - GRANT_EXECUTE
      - OWNERSHIP

  - function:
      name_regexp: ".*_public"
    privileges:
      - EXECUTE

The configuration file for this rule set is as follows:

resource "yandex_trino_access_control" "trino_access_control" {
  ...
  cluster_id  = <cluster_ID>
  functions = [
    {
      users         = ["banned_user_id"]
    },
    {
      groups        = ["admins_group_id"]
      privileges    = ["GRANT_EXECUTE", "OWNERSHIP"]
    },
    {
      function      = {
        name_regexp = ".*_public"
      }
      privileges    = ["EXECUTE"]
    }
  ]
  ...
}

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

{
  "updateMask": "trino.accessControl.functions",
  "trino": {
    "accessControl": {
      "functions": [
        {
          "users": [
            "banned_user_id"
          ]
        },
        {
          "groups": [
            "admins_group_id"
          ],
          "privileges": [
            "GRANT_EXECUTE",
            "OWNERSHIP"
          ]
        },
        {
          "function": {
            "nameRegexp": ".*_public"
          },
          "privileges": [
            "EXECUTE"
          ]
        }
      ]
    }
  }
}

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

{
  "cluster_id": "<cluster_ID>",
  "update_mask": {
    "paths": [
      "trino.access_control.functions"
    ]
  },
  "trino": {
    "access_control": {
      "functions": [
        {
          "users": [
            "banned_user_id"
          ]
        },
        {
          "groups": [
            "admins_group_id"
          ],
          "privileges": [
            "GRANT_EXECUTE",
            "OWNERSHIP"
          ]
        },
        {
          "function": {
            "name_regexp": ".*_public"
          },
          "privileges": [
            "EXECUTE"
          ]
        }
      ]
    }
  }
}
Previous
Assigning rules for tables
Next
Assigning rules for procedures