01.elasticsearch-security

文章目录

1.概述
2. xpack.security.enabled的作用
- 2.1 实验一
- - 1.生成ca文件
  - 2.elastisearch.yml中进行相关的配置，开启了node之间transport层面使用ssl
  - 3.访问测试
3.创建用户信息，跳过build-in user的初始化
- 3.1 配置file realm
- 3.2 kibana配置
- 3.3 使用kibana创建用户测试
4.anonymous 用户的测试
- 4.1 es设置
- 4.2 访问测试
5. role中的run as 功能
- 5.1 配置一个更低权限的user
- 5.1 给run_user 配置一个run as 权限
6.开启http层面是ssl/tsl加密

1.概述

es 官方有security开启的操作流程，这篇文章的主要是为了搞清楚这些流程中的每一步是否必要，有什么含义。先总结官方步骤如下

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

2. xpack.security.enabled的作用

最开始的时候,我以为这个仅仅是开启设置，强制要求进行node间的encrypt通信，实验的时候才发现，xpack.security.enabled会开启集群的node之间的encrypt通信的要求，同时也会开启基于user-password的访问特性。

2.1 实验一

1.生成ca文件

bin/elasticsearch-certutil ca
生成 elastic-stack-ca.p12 文件,中间一路回车，不用设置密码bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
生成 elastic-certificates.p12,中间一路回车，不设置密码mkdir config/certs
mv  elastic-stack-ca.p12   elastic-certificates.p12 config/certs/

2.elastisearch.yml中进行相关的配置，开启了node之间transport层面使用ssl

## security 相关
xpack.security.enabled: true### 1. tcp层配置
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12

3.访问测试

这个时候集群的启动是正常的，但是使用curl访问的时候

curl 10.76.3.145:12200 |jq '.'
{"status": 401,"error": {"header": {"WWW-Authenticate": "Basic realm=\"security\" charset=\"UTF-8\""},"reason": "failed to authenticate user [elastic]","type": "security_exception","root_cause": [{"header": {"WWW-Authenticate": "Basic realm=\"security\" charset=\"UTF-8\""},"reason": "failed to authenticate user [elastic]","type": "security_exception"}]}
}

发现需要用户信息，必须使用用户才能够正常的访问。
使用默认的用户信息

curl -u 'elastic:changeme'  10.76.3.145:12200 |jq '.'

访问发现也是不行的，通过文档查找知道es已经取消了这些用户的默认密码，只有手动修改激活之后才是可以正常使用的。

3.创建用户信息，跳过build-in user的初始化

因为上面的讨论中认为xpack.security.enabled会开启集群的node之间的encrypt通信的要求，同时也会开启基于user-password的访问特性，初步思考，认为build-in user只是user中的一个很小的部分，是为了让user使用更加方便的,并不算是一个独立的功能，所以步骤6并不是必须的。

为了验证一下，这里并没有进行build-in user的初始化过程。直接在每个node上配置了file realm

3.1 配置file realm

es 目录下执行

./bin/elasticsearch-users  useradd  chencc -p chencc -r superuser

bin/elasticsearch-users listchencc         : superuser

这个命令会在config下的 users_roles, users文件下生成了role和user信息，用户为checc, password 为chencc, role为bulid-in role superuser,这个role默认拥有所有的权限，
参照这里，这里和这里

es配置


## security 相关
xpack.security.enabled: true### 1. tcp层配置
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12xpack.security.authc.realms.file.file1.order: 0

3.2 kibana配置


server.name: dev-log
server.port: 45601
server.host: 10.76.0.129
elasticsearch.hosts: ["http://10.76.0.98:12200"]
elasticsearch.username: chencc
elasticsearch.password: chenccxpack.monitoring.kibana.collection.enabled: true
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.hosts: ["http://10.76.0.98:12200"]
xpack.monitoring.elasticsearch.username: chencc
xpack.monitoring.elasticsearch.password: chencc

注意两个地方都要配置user,password才行。
然后使用 chencc登录kibana发现还都是好使的，哈哈哈。

curl -u 'chencc:chencc'  10.76.3.145:12200 |jq '.'
{"tagline": "You Know, for Search","version": {"minimum_index_compatibility_version": "6.0.0-beta1","number": "7.3.0","build_flavor": "default","build_type": "tar","build_hash": "de777fa","build_snapshot": false,"lucene_version": "8.1.0","minimum_wire_compatibility_version": "6.8.0"},"cluster_uuid": "aT2wHdDBQDSguyDjgAzHzw","cluster_name": "dev-log","name": "ES02"
}

这也是说明了并不一定绝对依赖build-in user，他是es的提供的方便，但是实际使用中肯定还是建议激活的，这些用户都对应了一些特定的场景，可以更加方便快捷的进行权限划分。但是在kibana的管理页面是看不到这个用户的存在的，应该是无法通过api修改权限的
但是我们可以将file realm定义的用户合并到native ,参考这里

To migrate file-based users to the native realm, use the migrate tool.

但是这个工具在7.2的时候已经过期了，官方建议是直接使用native realm即可

同时，对于file-realm的使用，es官方的建议是配置一个高级别的管理员用户，在其他用户都被lock的时候用户重置其他用户。参考这里

3.3 使用kibana创建用户测试

既然chencc可以拥有所有的权限，不妨索性创建两个用户试试，在kibana的管理页面创建了一个role为superuser的用户chen_test,但是用这个用户来登录kibana的时候，发现不行。使用curl访问的时候也报没有权限。

curl -u 'chen_super:chen_super'  10.76.3.145:12200 |jq '.'{"status": 401,"error": {"header": {"WWW-Authenticate": "Basic realm=\"security\" charset=\"UTF-8\""},"reason": "unable to authenticate user [chen_super] for REST request [/]","type": "security_exception","root_cause": [{"header": {"WWW-Authenticate": "Basic realm=\"security\" charset=\"UTF-8\""},"reason": "unable to authenticate user [chen_super] for REST request [/]","type": "security_exception"}]}
}

这个时候想到有可能额因为每个es node中显式的配置了file realm ,导致了native-realm被禁用了（kibana创建的属于native realm）。所以创建的用户没有办法使用了。参考这里

The file realm is added to the realm chain by default.
You don’t need to explicitly configure a file realm.

and 这里

The native realm is available by default when no other realms are configured.
If other realm settings have been configured in elasticsearch.yml,
you must add the native realm to the realm chain.

所以所显式的打开native试试


## security 相关
xpack.security.enabled: true### 1. tcp层配置
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12xpack.security.authc.realms.file.file1.order: 0
xpack.security.authc.realms.native.native1.order: 1

果然，打开native之后就可以了，无论是kibana登录还是curl访问，啊啊啊。
如何进行带有user-password的请求参考这里

curl -u 'chen_super:chen_super'  10.76.3.145:12200 |jq '.'
{"tagline": "You Know, for Search","version": {"minimum_index_compatibility_version": "6.0.0-beta1","number": "7.3.0","build_flavor": "default","build_type": "tar","build_hash": "de777fa","build_snapshot": false,"lucene_version": "8.1.0","minimum_wire_compatibility_version": "6.8.0"},"cluster_uuid": "aT2wHdDBQDSguyDjgAzHzw","cluster_name": "dev-log","name": "ES02"
}

这里说明了即使关掉了native,使用kibana和响应的api都是还是可以创建用户的，但是不能正常使用。必须在开启了native之后这些用户才是可以使用的。

4.anonymous 用户的测试

es还允许你配置一个匿名用户来进行访问，你可以对这个用户进行role的设置，决定了如果一个访问没有携带用户信息的话，就使用配置的匿名用户来进行鉴权，后面的测试发现，如果请求携带的用户权限不够，也会尝试使用配置的anonymous用户来代替鉴权。

4.1 es设置


## security 相关
xpack.security.enabled: true### 1. tcp层配置
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12## 2. realm 配置
xpack.security.authc.realms.file.file1.order: 0
xpack.security.authc.realms.native.native1.order: 1## 3. 匿名配置
xpack.security.authc:anonymous:username: anonymous_userroles: superuser,kibana_userauthz_exception: true

4.2 访问测试


curl  10.76.3.145:12200 |jq '.'
{"tagline": "You Know, for Search","version": {"minimum_index_compatibility_version": "6.0.0-beta1","number": "7.3.0","build_flavor": "default","build_type": "tar","build_hash": "de777fa","build_snapshot": false,"lucene_version": "8.1.0","minimum_wire_compatibility_version": "6.8.0"},"cluster_uuid": "aT2wHdDBQDSguyDjgAzHzw","cluster_name": "dev-log","name": "ES02"
}

可以看到，不带用户信息进行访问，也能够通过，但是假如你携带了用户的信息，但是这个用户不存在，或者密码错误，这还是会返回失败的哦。

5. role中的run as 功能

在es的权限中中还有一种是run as 权限，也就是允许你run as另一个用户。
这个时候，另一个用户其实也就成了一种权限，类似一个role一样。
这个功能的解释我看了半天没有看懂，最后竟然还是借助google翻译看懂的，大哭。