内置系统访问控制

系统访问控制插件在任何连接器级别授权之前,对全局级别强制授权。您可以选择使用openLooKeng的任一内置的插件,或者按照系统访问控制中的指导提供您自己的插件。openLooKeng提供了三个内置插件:

插件说明
allow-all(缺省值)允许所有操作。
read-only允许读数据或读元数据的操作,但不允许写数据或写元数据的操作。有关详细信息,请参阅”只读系统访问控制”。
file使用配置属性security.config-file指定的配置文件执行授权检查。有关详细信息,请参阅“基于文件的系统访问控制”。

允许所有系统访问控制

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

只读系统访问控制

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

  1. access-control.name=read-only

基于文件的系统访问控制

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

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

配置文件必须是JSON格式,它包含:

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

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

刷新

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

  1. security.refresh-period=1s

目录规则

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

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

注意

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

例如,如果希望仅允许admin用户访问mysqlsystem目录,允许所有用户访问hive目录,拒绝其他用户访问,则可以定义以下规则:

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

用户模拟规则

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

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

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

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

如下示例所示,允许alicebob两位管理员可以模拟除了对方外的其他任意用户;同时,允许任意用户模拟test用户:

  1. {
  2. "impersonation": [
  3. {
  4. "original_user": "alice",
  5. "new_user": "bob",
  6. "allow": false
  7. },
  8. {
  9. "original_user": "bob",
  10. "new_user": "alice",
  11. "allow": false
  12. },
  13. {
  14. "original_user": "alice|bob",
  15. "new_user": ".*"
  16. },
  17. {
  18. "original_user": ".*",
  19. "new_user": "test"
  20. }
  21. ]
  22. }

主体规则

警告

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

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

  • principal (必选):要匹配的正则表达式和针对主体的组。

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

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

  • allow(必须):布尔类型,表示是否允许授予主体用户权限。

注意

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

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

  1. {
  2. "catalogs": [
  3. {
  4. "allow": true
  5. }
  6. ],
  7. "principals": [
  8. {
  9. "principal": "(.*)",
  10. "principal_to_user": "$1",
  11. "allow": true
  12. },
  13. {
  14. "principal": "([^/]+)(/.*)?@.*",
  15. "principal_to_user": "$1",
  16. "allow": true
  17. }
  18. ]
  19. }

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

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

节点信息规则

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

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

注意

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

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

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

启发式索引控制规则

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

每条规则由以下部分组成:

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

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

  1. {
  2. "indexAccess": [
  3. {
  4. "user": "tom",
  5. "privileges": ["SHOW", "CREATE"]
  6. },
  7. {
  8. "user": "admin",
  9. "privileges": ["ALL"]
  10. }
  11. ]
  12. }