3.5. Built-in System Access Control

A system access control plugin enforces authorization at a global level,before any connector level authorization. You can either use one of the built-inplugins in Presto or provide your own by following the guidelines inSystem Access Control. Presto offers three built-in plugins:

Allow All System Access Control

All operations are permitted under this plugin. This plugin is enabled by default.

Read Only System Access Control

Under this plugin, you are allowed to execute any operation that reads data ormetadata, such as SELECT or SHOW. Setting system level or catalog levelsession properties is also permitted. However, any operation that writes data ormetadata, such as CREATE, INSERT or DELETE, is prohibited.To use this plugin, add an etc/access-control.propertiesfile with the following contents:

access-control.name=read-only

File Based System Access Control

This plugin allows you to specify access control rules in a file. To use thisplugin, add an etc/access-control.properties file containing two requiredproperties: access-control.name, which must be equal to file, andsecurity.config-file, which must be equal to the location of the config file.For example, if a config file named rules.jsonresides in etc, add an etc/access-control.properties with the followingcontents:

access-control.name=file
security.config-file=etc/rules.json

The config file is specified in JSON format.

• It contains the rules defining which catalog can be accessed by which user (see Catalog Rules below).
• The principal rules specifying what principals can identify as what users (see Principal Rules below).This plugin currently only supports catalog access control rules and principalrules. If you want to limit access on a system level in any other way, youmust implement a custom SystemAccessControl plugin(see System Access Control).

Refresh

By default, when a change is made to the security.config-file, Presto must be restartedto load the changes. There is an optional property to refresh the properties without requiring aPresto restart. The refresh period is specified in the etc/access-control.properties:

security.refresh-period=1s

Catalog Rules

These rules govern the catalogs particular users can access. The user isgranted access to a catalog based on the first matching rule read from top tobottom. If no rule matches, access is denied. Each rule is composed of thefollowing fields:

• user (optional): regex to match against user name. Defaults to .*.
• catalog (optional): regex to match against catalog name. Defaults to .*.
• allow (required): boolean indicating whether a user has access to the catalog

Note

By default, all users have access to the system catalog. You canoverride this behavior by adding a rule.

For example, if you want to allow only the user admin to access themysql and the system catalog, allow all users to access the hivecatalog, and deny all other access, you can use the following rules:

{
  "catalogs": [
    {
      "user": "admin",
      "catalog": "(mysql|system)",
      "allow": true
    },
    {
      "catalog": "hive",
      "allow": true
    },
    {
      "catalog": "system",
      "allow": false
    }
  ]
}

Principal Rules

These rules serve to enforce a specific matching between a principal and aspecified user name. The principal is granted authorization as a user basedon the first matching rule read from top to bottom. If no rules are specified,no checks will be performed. If no rule matches, user authorization is denied.Each rule is composed of the following fields:

• principal (required): regex to match and group against principal.
• user (optional): regex to match against user name. If matched, itwill grant or deny the authorization based on the value of allow.
• principal_to_user (optional): replacement string to substitute againstprincipal. If the result of the substitution is same as the user name, it willgrant or deny the authorization based on the value of allow.
• allow (required): boolean indicating whether a principal can be authorizedas a user.

Note

You would at least specify one criterion in a principal rule. If you specifyboth criteria in a principal rule, it will return the desired conclusion wheneither of criteria is satisfied.

The following implements an exact matching of the full principal name for LDAPand Kerberos authentication:

{
  "catalogs": [
    {
      "allow": true
    }
  ],
  "principals": [
    {
      "principal": "(.*)",
      "principal_to_user": "$1",
      "allow": true
    },
    {
      "principal": "([^/]+)/?.*@.*",
      "principal_to_user": "$1",
      "allow": true
    }
  ]
}

If you want to allow users to use the extractly same name as their Kerberos principalname, and allow alice and bob to use a group principal named asgroup@example.net, you can use the following rules.

{
  "catalogs": [
    {
      "allow": true
    }
  ],
  "principals": [
    {
      "principal": "([^/]+)/?.*@example.net",
      "principal_to_user": "$1",
      "allow": true
    },
    {
      "principal": "group@example.net",
      "user": "alice|bob",
      "allow": true
    }
  ]
}