内置系统访问控制

此插件允许所有操作。此插件默认开启。

通过此插件，您可以执行任何读取数据或元数据的操作，例如SELECT或SHOW。还允许设置系统级或目录级会话属性。但是禁止任何写数据或元数据的操作，如CREATE、INSERT、DELETE等。 要使用此插件，请添加etc/access-control.properties文件，文件内容如下：

此插件允许您在文件中设置访问控制规则。要使用该插件，需要添加一个etc/access-control.properties文件，其中必需包含两个属性：Access-control.name属性，必须等于file；security.config-file属性，必须等于配置文件所在的位置。例如，配置文件rules.json位于etc目录，则添加etc/access-control.properties文件，内容如下：

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

配置文件必须是JSON格式，它包含：

• 定义哪个用户可以访问哪些目录的规则（见下面的目录规则）。
• 明确哪些主体可以标识为哪些用户的规则（见下文的主体规则）。

此插件目前仅支持目录访问控制规则和主体规则。如果您想以任何其他方式进行系统级访问限制，您必须实现一个自定义的SystemAccessControl插件（参见系统访问控制）。

默认情况下，修改security.config-file后，必须重新启动openLooKeng以加载所做的更改。有一个可选的属性可以不需要重启openLooKeng就能刷新属性。刷新周期在etc/access-control.properties中指定：

security.refresh-period=1s

目录规则

目录规则控制特定用户可以访问的目录。根据从上到下读取匹配到的第一个规则，授予用户访问目录的权限。如果没有匹配到任何规则，则拒绝访问。每条规则由以下字段组成：

• user（可选）：用于匹配用户名的正则表达式。默认为.*。
• catalog（可选）:用于匹配目录名的正则表达式。默认为.*。
• allow（必选）: 布尔类型参数，表示用户是否有访问目录的权限

注意

默认情况下，所有用户都可以访问system目录。您可以通过添加规则来改变此行为。

用户模拟规则用于控制一个用户模拟另一个用户的能力。在某些环境中，希望管理员（或管理系统）代表其他用户运行查询，这时管理员将使用其凭据进行身份认证，然后以其他用户提交查询。当用户上下文改变后，openLooKeng将验证管理员是否有权以目标用户身份运行查询。

如果存在用户模拟规则，基于从上到下第一个匹配的规则进行映射。如果没有规则匹配，则认证被拒绝。如果不设置用户模拟规则，但指定遗留的主体规则，则假定主体规则正在进行用户模拟的权限控制，允许主体规则进行用户模拟。如果用户模拟规则和主体规则均未定义，则不允许用户模拟。

每个用户模拟规则均由以下字段组成：

• original_user （必选）： 正则表达式以匹配请求模拟的用户。
• new_user （必选）： 正则表达式以匹配将被模拟的用户。
• allow （可选）： 布尔值，指示是否应允许认证。

如下示例所示，允许alice和bob两位管理员可以模拟除了对方外的其他任意用户；同时，允许任意用户模拟test用户：

{
    "impersonation": [
        {
            "original_user": "alice",
            "new_user": "bob",
            "allow": false
        },
        {
            "new_user": "alice",
            "allow": false
        },
            "original_user": "alice|bob",
            "new_user": ".*"
        },
        {
            "original_user": ".*",
            "new_user": "test"
        }
    ]
}

主体规则

警告

• 主体规则将在以后的版本中删除，不推荐使用。 主体规则已被替换为（指定了如何将复杂的认证用户名映射到openLooKeng的简单用户名）和上面定义的用户模拟规则。

这些规则用于强制主体和指定的用户名之间的特定匹配。根据从上到下读取匹配的第一个规则，以用户身份为主体授权。 如果没有指定规则，则不进行检查。如果没有匹配到任何规则，则拒绝用户授权。每条规则由以下字段组成：

• principal （必选）：要匹配的正则表达式和针对主体的组。

• user（可选）：用于匹配用户名的正则表达式。如果匹配成功，则根据allow的值进行授权或拒绝授权。

• principal_to_user（可选）：替换主体的字符串。如果替换的结果与用户名相同，则根据allow的值授予或拒绝授权。

注意

一条主体规则中至少要指定一个条件。如果在主体规则中指定了两个条件，当满足其中一个条件时，主体规则将返回期望的结论。

以下实现LDAP认证和Kerberos认证的主体完整名称的精确匹配：

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

如果希望允许用户使用与其Kerberos主体名称相同的名称，并且允许alice和bob使用名为group@example.net的组主体，那么可以使用以下规则：

节点信息规则控制特定用户可以更新节点状态。根据从上到下读取匹配到的第一个规则，授予用户更新节点状态的权限。如果没有匹配到任何规则，则拒绝访问。每条规则由以下字段组成：

• user（可选）：用于匹配用户名的正则表达式。默认为.*。
• allow（必选）: 布尔类型参数，表示用户是否有更新节点状态的权限

注意

默认情况下，所有用户都不可以更新节点状态。您可以通过添加规则来改变此行为。

例如，如果希望仅允许admin用户以及更新节点状态，则可以定义以下规则：

{
  "nodeInfo": [
    {
      "user": "admin",
      "allow": true
    },
    {
      "user": "alice",
      "allow": true
    },
    {
      "user": "bob",
      "allow": false
    }
  ]
}

启发式索引控制规则

这些规则控制了允许的启发式索引操作。

• user (必要): 匹配用户名称的正则表达式。默认值：.*.
• privileges (可选): 授予用户的权限 (ALL, SHOW, CREATE, DROP, RENAME, and UPDATE). 默认值 ALL.

在下面这个例子中，用户tom只能执行SHOW INDEX或CREATE INDEX指令。 用户admin可以执行CREATE INDEX, SHOW INDEX, DROP INDEX等所有指令.

{
  "indexAccess": [
    {
      "user": "tom",
      "privileges": ["SHOW", "CREATE"]
    },
    {
      "user": "admin",
      "privileges": ["ALL"]
    }
  ]
}