基于open_distro的ES用户管理（授权）

背景

open distro for elasticsearch 是由亚马逊AWS支持的基于Apache License,Version 2.0协议的100%开源的Elasticsearch发行版。与Elastic公司官方的Elasticsearch版本最大的区别是:剔除了基于elastic协议发布的xpack插件,增加了开源插件。新增插件功能包括安全、告警、索引生命周期管理、性能分析、SQL等企业级功能。简单理解就是集成了开源版xpack插件的elasticsearch。

用户授权

在通过用户认证后，open_distro_security插件需要一系列机制进行用户授权，来验证用户可以执行哪些操作，不允许执行哪些操作。open_distro_security也提供了RBAC（基于角色的访问控制），简单来说就是：先创建角色，角色拥有一系列权限，再把角色赋予用户，最后计算得出某个用户具体拥有哪些权限。关于用户角色映射（map users to roles）的理解：一般情况下，创建用户后，给用户赋予角色。但是在open_distro_security插件中这个过程是相反的，是创建角色后，把角色和用户关联映射起来。

概念

  • 被保护资源
    被保护的资源分为两个类：集群和索引，被保护（访问控制的对象）可以是某个索引的数据，也可以是某个API。
  • 权限（permission）
    可以在某个被保护资源上执行的操作，详细权限列表参见文档通常情况下，不建议直接给用户赋予权限，而应该给用户添加动作组。
  • 动作组（Action Group）
    单个权限的控制粒度太细了，一组相关权限的组合就称为“动作组”。创建新组的最佳实践是：在已有的组上，赋予新的权限，而不是创建一个全新的组。默认的动作组有：
  • 通用（可以用在索引和集群控制上）
  • UNLIMITED：没有限制
  • 集群级别
  • CLUSTER_ALL
  • CLUSTER_MONITOR
  • CLUSTER_COMPOSITE_OPS_RO
  • CLUSTER_COMPOSITE_OPS
  • MANAGE_SNAPSHOTS
  • 索引级别
  • INDICES_ALL
  • GET
  • READ
  • WRITE
  • DELETE
  • CRUD
  • SEARCH
  • SUGGEST
  • CREATE_INDEX
  • INDICES_MONITOR
  • MANAGE_ALIASES
  • MANAGE
  • 角色（Role）
    在角色中需定义名称、集群权限(集群动作组)、要保护的索引、索引权限（索引动作组）、文档级控制权限、字段级控制权限。插件默认有一些初始化好的角色，如：
  • all_access
  • readall
  • kibana_server

授权方式

在open_distro security的安全插件中可以通过三种方式打到授权的目的：

  • 通过配置文件管理
    在$ES_HOME/plugins/opendistro_security/securityconfig 目录中的roles.yml和roles_mapping.yml，并用/plugins/opendistro_security/tools/securityadmin.sh 完成初始化。
  • 通过kibana图形化界面
    使用opendistroforelasticsearch 版本的kibana 管理工具，Security模块进行Users、Roles、RoleMapping的管理工作
  • 通过Restful API接口
    配置文件的方式适合系统第一次安装后的初始化场景，kibana图形化界面适用临时运维管理。只有Restful API接口适合软件研发过程中的管理工作，且能以脚本的形式归档和统一分发执行。所以详细介绍一下通过API命令

API管理命令

  • 创建角色
PUT _opendistro/_security/api/roles/test_role2
{
  "cluster_permissions":["cluster_composite_ops","indices_monitor"],
  "index_permissions":[
    {
      "index_patterns":["test*"],
      "allowed_actions":[
          "read","write"
        ]
    }
    ],
  "tenant_permissions":[]
}
  • 删除角色
DELETE _opendistro/_security/api/roles/test_role2
  • 获取角色
GET _opendistro/_security/api/roles/
  • 将新建的角色赋予用户
PUT _opendistro/_security/api/rolesmapping/test_role2
{
   "users":[test_user2]
}

注意事项及疑问

  • 新建的自定义角色，必须通过rolesmapping API 将角色和用户映射起来（用户赋予角色），否则用户没权限
  • 没有通过rolesmapping API而直接在创建用户的backend_roles中指定该角色，不起作用，无效。
  • rolesmapping/<rol> role 必须是自定义的角色名，不是任意字符串
  • 疑问：创建用户时的backend_roles和自定义角色是什么关系？