基於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和自定義角色是什么關系？