02.elasticsearch-security_es权限管理API概览

最新推荐文章于 2024-08-11 16:25:34 发布

夜月行者

最新推荐文章于 2024-08-11 16:25:34 发布

阅读量3.9k

点赞数 1

分类专栏： # security权限管理文章标签： java 大数据

本文链接：https://blog.csdn.net/u013200380/article/details/106875921

版权

security权限管理专栏收录该内容

2 篇文章 2 订阅

订阅专栏

文章目录

1.es权限管理简介

这里主要学习一下es基于用户的权限管理是怎么运转的。在权限管理中有这样几个部分,es内部的权限管理可以认为是遵循了RBAC的模式，Role-Based-Access-Control , 对应的有这么些概念

secured resource 需要限制访问的资源（索引，doc,field, aliases等）
privilege 一些执行动作，（write,read）
permissions 权限，是对某个资源可以执行哪些的动作的集合，比如可以对 topic这个index执行写操作，就是一个permission
role 是permissions的集合

1.1 role的权限定义

用户user的创建比较简单，都是直接和role进行关联,所以role的定义变得很有内容。

PUT /_security/role/<name>
{
  "run_as": [ ... ],
  "cluster": [ ... ],
  "global": { ... },
  "indices": [ ... ],
  "applications": [ ... ]

}

可以看到，为一个role分配权限的时候包括了这样几个部分
1.run_as: 可以按照别的用户的权限来给自己授予权限
2.cluster: 集群级别的权限，主要是集群管理，监控等权限
3.global: global权限是用来管理application的，下面会详述
4.indices：这个是最常用的，就是对那些索引有什么操作权限权限
5.applications: 这个是为那些自定义权限的组件定义的，定义比较灵活

一个实例

POST /_security/role/my_admin_role
{
  "cluster": ["all"],
  "indices": [
    {
      "names": [ "index1", "index2" ],
      "privileges": ["all"],
      "field_security" : { // optional
        "grant" : [ "title", "body" ]
      },
      "query": "{\"match\": {\"title\": \"foo\"}}" // optional
    }
  ],
  "applications": [
    {
      "application": "myapp",
      "privileges": [ "admin", "read" ],
      "resources": [ "*" ]
    }
  ],
  "run_as": [ "other_user" ], // optional
  "metadata" : { // optional
    "version" : 1
  }
}

1.2 创建user

POST /_security/user/jacknich
{
  "password" : "j@rV1s",
  "roles" : [ "admin", "other_role1" ],
  "full_name" : "Jack Nicholson",
  "email" : "jacknich@example.com",
  "metadata" : {
    "intelligence" : 7
  }
}

上面的过程简单的展示了创建user和role的过程。

2. es创建role的权限详解

通过上面已经简单了解了role的权限构成，这里会详细的介绍各个组成部分。其实对于es的主要的权限管理还是在cluster和indeces上面，run_as算是一种授权的方式，并不代表了具体的权限，applications这个是周边组件自定义权限使用，下面会详述。权限被划分为cluster级别和indices级别。

2.1 run_as权限

run_as,对应的属性值就是一系列的user 的权限，在上一篇中已经介绍过run_as的功能了，他只是为了授权更方便，并不改变基本的权限粒度

2.2 cluster 相关权限

cluster级别的权限也有很多,大部分都是集群状态数据的管理

权限大类别	权限明细	含义
cluster
	all	所有cluster级别的权限
	create_snapshot	为现有的数据创建快照的权限
	manage	对集群的管理权限，包括集群的设置，rerouting等，但是不包括对security的管理
	manage_ccr	跨集群副本操作的权限
	manage_ilm	index life manage,对索引的生命周期管理的权限，对roll up的索引进行管理
	manage_index_templates	All operations on index templates.
	manage_ingest_pipelines	All operations on ingest node pipelines.
	manage_ml	机器学习相关
	manage_pipeline	All operations on ingest pipelines.
	manage_rollup	对rollup的操作任务进行管理，包括创建，开始，停止，删除
	manage_saml	SAML 认证（收费项目）
	manage_security	所有security相关的操作，比如针对role和users的CRUD
	manage_token	token验证（收费项目）
	manage_watcher	监控报警相关(收费项目)
	monitor	对集群所有的查询接口的操作权限，比如cluster health,state,hot threads,node info,node and cluster stats,pending cluster tasks
	monitor_ml	关于机器学习的所有查询操作（收费项目）
	monitor_rollup	针对roll up功能的所有查询操作，查询当前的rollup jobs等操作
	monitor_watcher	针对报警功能的查询操作（收费项目）
	read_ccr	跨集群相关的一些读操作（收费项目）
	read_ilm	index lifecycle management 的查询操作，比如获取policies或者检查status
	transport_client	transport client 连接需要的所有权限

2.3 indices 相关权限

对哪些索引(支持*正则等)有哪些权限（read,write,create,等等）

权限大类别	权限明细	含义
index
	all	Any action on an index
	create	创建documents,但是对于已经存在doc可能会失败
	create_index	创建index的权限，如果一个创建索引的请求同时包含了aliases操作，那么这个请求的用户同时需要对index和aliase有 "manage"权限
	delete	Privilege to delete documents
	delete_index	Privilege to delete an index
	index	Privilege to index and update documents. Also grants access to the update mapping action
	manage	所有的"monitor"权限，外加对index的管理员权限(aliases,analyze,cache clear,close,delete,exitsts,flush,mapping,open,force merge, refresh,settings,search shards, templates, validate)
	manage_follow_index	只对有follower index的有关
	manage_ilm	All index lifecycle management operations 包括retrying policies, and removing a policy from an index.
	manage_leader_index	只对有follower index的有关
	monitor	All actions that are required for monitoring (recovery, segments info, index stats and status).
	read	只读权限(count, explain, get, mget, get indexed scripts, more like this, multi percolate/search/termvector, percolate, scroll, clear_scroll, search, suggest,tv)
	read_cross_cluster	跨集群操作
	view_index_metadata	对index metadata的只读权限，针对（aliases, aliases exists, get index, exists, field mappings, mappings, search shards, type exists, validate, warmers, settings, ilm）
	write	对docment操作的所有写相关的权限，包括（index, update, delete documents ,bulk operations）,同时也有update mapping的权限

2.4 applications相关权限

2.4.1 application 作用含义

这个虽然知道api和形式，但是不知道怎么用,看他官方的解释是这个样子的这里

They do not, however, grant access to any actions or resources within Elasticsearch.
 Their purpose is to enable applications to represent 
 and store their own privilege models within Elasticsearch roles.

这一段的描述说的大概是指application的配置并不会授予当前role任何elasticsearch的资源（cluster相关操作，indices相关的操作），他是为了让周边的应用比如kibana,filebeat能够用他们自己的方式授权。比如kibana，有很多自己的菜单页，没有必要把这些菜单页都对应成一个es的索引（这样很麻烦，而且很浪费），所以kibana自己定义了一些权限，这些权限统一以applications的形式存储在es当中了。然后自己通过一个名字为kibana-.kibana 的application来记录有哪些权限。

GET /_security/privilege/kibana-.kibana
{"kibana-.kibana" : {
   "feature_apm.read" : {
      "application" : "kibana-.kibana",
      "name" : "feature_apm.read",
      "actions" : [
        "saved_object:7.3.0:url/find",
        "saved_object:7.3.0:url/get",
        "login:",
        "saved_object:7.3.0:config/bulk_get",
        "ui:7.3.0:apm/show",
        "saved_object:7.3.0:url/bulk_get",
        "saved_object:7.3.0:config/find",
        "ui:7.3.0:navLinks/apm",
        "saved_object:7.3.0:config/get",
        "api:7.3.0:apm",
        "version:7.3.0",
        "app:7.3.0:kibana",
        "ui:7.3.0:catalogue/apm",
        "app:7.3.0:apm"
      ],
      "metadata" : { }
    },
    "feature_graph.read" : {
      "application" : "kibana-.kibana",
      "name" : "feature_graph.read",
      "actions" : [
        "saved_object:7.3.0:url/find",
        "saved_object:7.3.0:url/get",
        "ui:7.3.0:navLinks/graph",
        "login:",
        "saved_object:7.3.0:config/bulk_get",
        "saved_object:7.3.0:url/bulk_get",
        "saved_object:7.3.0:graph-workspace/get",
        "saved_object:7.3.0:config/find",
        "saved_object:7.3.0:graph-workspace/find",
        "saved_object:7.3.0:index-pattern/find",
        "saved_object:7.3.0:index-pattern/get",
        "app:7.3.0:graph",
        "saved_object:7.3.0:config/get",
        "saved_object:7.3.0:graph-workspace/bulk_get",
        "saved_object:7.3.0:index-pattern/bulk_get",
        "version:7.3.0",
        "app:7.3.0:kibana",
        "ui:7.3.0:catalogue/graph"
      ],
      "metadata" : { }
    }
  }
}

这里的application 的name是kibana-.kibana，然后他里面自定义了很多的权限(privilege)，像feature_apm.read, feature_graph.read都是其中的一个权限。在创建role的时候需要选择application的那个privilege

2.4.2 application创建

PUT /_security/privilege
{
  "myapp": {
    "read": {
      "actions": [
        "data:read/*" ,
        "action:login" ],
        "metadata": {
          "description": "Read access to myapp"
        }
      }
    }
}

es对application的结构特征有要求，但是很多key都不是固定的。
1.myapp:对应了application的name
2.read :对应了myapp的一个privilege,和上面的kibana-.kibana application中的feature_apm.read, feature_graph.read是同一个级别的东西,可以是任意字符串
3.actions:这个是固定出现的，里面配置的就是具体的自定义的promission
4.metadata: 可选的，用于描述一些辅助信息
创建role的时候使用的方式

{
  "run_as": [ ... ],
  "cluster": [ ... ],
  "global": { ... },
  "indices": [ ... ],
  "applications": [ ... ]

}

{
  "application": "my_app",
  "privileges": [ ... ],
  "resources": [ ... ]
}

2.5 global相关权限

global权限是用来管理application,文档上面说global支持的唯一权限就是能够管理哪些application
参考这里

The only supported global privilege
 is the ability to manage application privileges

也就是说这个只有在创建role的时候直接使用那些已经定义好的application
创建的样例

{
  "run_as": [ ... ],
  "cluster": [ ... ],
  "global": { ... },
  "indices": [ ... ],
  "applications": [ ... ]

}

对应global的结构是
{
  "application": {
    "manage": {
        "applications": [ ... ]
    }
  }
}

2.6 es中build-in role

es中内建了一些role来辅助快速创建用户

beats_system
kibana_dashboard_only_user
kibana_system
kibana_user
logstash_system
superuser

2.7 es中的build-in user

elastic 超管

kibana
The user Kibana uses to connect and communicate with Elasticsearch.
这个也是只是kibana使用的，你能看到哪些图取决于你登录使用的账户

logstash_system
The user Logstash uses when storing monitoring information in Elasticsearch.
这个是存储montiroring data使用的账户，如果想要对es写入数据，还需要自己创建一些账户
而且老版本的logstash_system好像是没有开启的，还需要注意

beats_system
The user the Beats use when storing monitoring information in Elasticsearch.

apm_system
The user the APM server uses when storing monitoring information in Elasticsearch.
remote_monitoring_user

需要注意的是这些用户都需要激活才能使用，关于激活的方式可以看这里

3. 权限role,user创建的入口

可以在kibana的ui页面创建
可以调用对应的rest API进行访问创建

4. 简单总结

到这里，终于把es的role给描述完了，啰里啰嗦的整了很多，希望后期再看的时候能够快速理解es的权限管理,最后，再来回顾一下es开启security的流程：

检查使用license,因为不同的license能够使用的权限验证方式也是不一样的。
检查集群，保证每一个node都进行了设置 xpack.security.enabled: true
这个会开启security设置，也就开启了node之间使用ssl和基于用户的访问模式
开启node之间的transport层面的ssl/tls
启动es
为build-in user设置password
选择一种realm的管理方式，basic只能使用 file,native两种方式，其他的都是收费的
创建一些role和user来进行使用