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

基于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和自定义角色是什么关系？