内置系统访问控制

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

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

允许所有系统访问控制

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

只读系统访问控制

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

access-control.name=read-only

基于文件的系统访问控制

此插件允许您在文件中设置访问控制规则。要使用该插件,需要添加一个etc/access-control.properties文件,其中必需包含两个属性:access-control.name属性,必须等于filesecurity.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(必选): 字符串参数,表示用户是否有访问目录的权限。这个值可以是all、read-only或none,默认为none。将此值设置为read-only,其行为与只读的系统访问控制插件相同。

注意

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

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

{
  "catalogs": [
    {
      "user": "admin",
      "catalog": "(mysql|system)",
      "allow": all
    },
    {
      "catalog": "hive",
      "allow": all
    },
    {
      "user": "alice",
      "catalog": "postgresql",
      "allow": "read-only"
    },
    {
      "catalog": "system",
      "allow": none
    }
  ]
}

用户模拟规则

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

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

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

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

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

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

主体规则

警告

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

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

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

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

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

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

注意

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

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

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

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

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

节点信息规则

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

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

注意

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

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

{
  "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 INDEXCREATE INDEX指令。 用户admin可以执行CREATE INDEX, SHOW INDEX, DROP INDEX等所有指令.

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

有奖捉虫

“有虫”文档片段

0/500

存在的问题

文档存在风险与错误

● 拼写,格式,无效链接等错误;

● 技术原理、功能、规格等描述和软件不一致,存在错误;

● 原理图、架构图等存在错误;

● 版本号不匹配:文档版本或内容描述和实际软件不一致;

● 对重要数据或系统存在风险的操作,缺少安全提示;

● 排版不美观,影响阅读;

内容描述不清晰

● 描述存在歧义;

● 图形、表格、文字等晦涩难懂;

● 逻辑不清晰,该分类、分项、分步骤的没有给出;

内容获取有困难

● 很难通过搜索引擎,openLooKeng官网,相关博客找到所需内容;

示例代码错误

● 命令、命令参数等错误;

● 命令无法执行或无法完成对应功能;

内容有缺失

● 关键步骤错误或缺失,无法指导用户完成任务,比如安装、配置、部署等;

● 逻辑不清晰,该分类、分项、分步骤的没有给出

● 图形、表格、文字等晦涩难懂

● 缺少必要的前提条件、注意事项等;

● 描述存在歧义

0/500

您对文档的总体满意度

非常不满意
非常满意

请问是什么原因让您参与到这个问题中

您的邮箱

创Issue赢奖品
根据您的反馈,会自动生成issue模板。您只需点击按钮,创建issue即可。
有奖捉虫