Built-in System Access Control

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

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

    This plugin allows you to specify access control rules in a file. To use this plugin, add an etc/access-control.properties file containing two required properties: access-control.name, which must be equal to file, and security.config-file, which must be equal to the location of the config file. For example, if a config file named rules.json resides in etc, add an etc/access-control.properties with the following contents:

    1. access-control.name=file
    2. 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).

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

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

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

    Note

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

    1. {
    2.   "catalogs": [
    3.     {
    4.       "user": "admin",
    5.       "allow": true
    6.     },
    7.     {
    8.       "catalog": "hive",
    9.       "allow": true
    10.     },
    11.     {
    12.       "catalog": "system",
    13.       "allow": false
    14.     }
    15.   ]
    16. }

    These rules serve to enforce a specific matching between a principal and a specified user name. The principal is granted authorization as a user based on 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, it will grant or deny the authorization based on the value of .
    • principal_to_user (optional): replacement string to substitute against principal. If the result of the substitution is same as the user name, it will grant or deny the authorization based on the value of allow.
    • allow (required): boolean indicating whether a principal can be authorized as a user.

    Note

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

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

    1. {
    2.     {
    3.       "allow": true
    4.     }
    5.   ],
    6.   "principals": [
    7.     {
    8.       "principal": "([^/]+)/?.*@example.net",
    9.       "principal_to_user": "$1",
    10.       "allow": true
    11.     },
    12.     {
    13.       "principal": "group@example.net",
    14.       "user": "alice|bob",
    15.       "allow": true
    16.     }
    17.   ]