01.elasticsearch-security_es鉴权机制
文章目錄
- 1.概述
- 2. xpack.security.enabled的作用
- 2.1 實(shí)驗(yàn)一
- 1.生成ca文件
- 2.elastisearch.yml中進(jìn)行相關(guān)的配置，開啟了node之間transport層面使用ssl
- 3.訪問測(cè)試
- 3.創(chuàng)建用戶信息，跳過build-in user的初始化
- 3.1 配置file realm
- 3.2 kibana配置
- 3.3 使用kibana創(chuàng)建用戶測(cè)試
- 4.anonymous 用戶的測(cè)試
- 4.1 es設(shè)置
- 4.2 訪問測(cè)試
- 5. role中的run as 功能
- 5.1 配置一個(gè)更低權(quán)限的user
- 5.1 給run_user 配置一個(gè)run as 權(quán)限
- 6.開啟http層面是ssl/tsl加密
1.概述
??es 官方有security開啟的操作流程，這篇文章的主要是為了搞清楚這些流程中的每一步是否必要，有什么含義。先總結(jié)官方步驟如下
這個(gè)會(huì)開啟security設(shè)置，也就開啟了node之間使用ssl和基于用戶的訪問模式
2. xpack.security.enabled的作用
??最開始的時(shí)候,我以為這個(gè)僅僅是開啟設(shè)置，強(qiáng)制要求進(jìn)行node間的encrypt通信，實(shí)驗(yàn)的時(shí)候才發(fā)現(xiàn)，xpack.security.enabled會(huì)開啟集群的node之間的encrypt通信的要求，同時(shí)也會(huì)開啟基于user-password的訪問特性。
2.1 實(shí)驗(yàn)一
1.生成ca文件
bin/elasticsearch-certutil ca 生成 elastic-stack-ca.p12 文件,中間一路回車，不用設(shè)置密碼bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 生成 elastic-certificates.p12,中間一路回車，不設(shè)置密碼mkdir config/certs mv elastic-stack-ca.p12 elastic-certificates.p12 config/certs/2.elastisearch.yml中進(jìn)行相關(guān)的配置，開啟了node之間transport層面使用ssl
## security 相關(guān) 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.p123.訪問測(cè)試
這個(gè)時(shí)候集群的啟動(dòng)是正常的，但是使用curl訪問的時(shí)候
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"}]} }發(fā)現(xiàn)需要用戶信息，必須使用用戶才能夠正常的訪問。
使用默認(rèn)的用戶信息
訪問發(fā)現(xiàn)也是不行的，通過文檔查找知道es已經(jīng)取消了這些用戶的默認(rèn)密碼，只有手動(dòng)修改激活之后才是可以正常使用的。
3.創(chuàng)建用戶信息，跳過build-in user的初始化
??因?yàn)樯厦娴挠懻撝姓J(rèn)為xpack.security.enabled會(huì)開啟集群的node之間的encrypt通信的要求，同時(shí)也會(huì)開啟基于user-password的訪問特性，初步思考，認(rèn)為build-in user只是user中的一個(gè)很小的部分，是為了讓user使用更加方便的,并不算是一個(gè)獨(dú)立的功能，所以步驟6并不是必須的。
為了驗(yàn)證一下，這里并沒有進(jìn)行build-in user的初始化過程。直接在每個(gè)node上配置了file realm
3.1 配置file realm
es 目錄下執(zhí)行
./bin/elasticsearch-users useradd chencc -p chencc -r superuser bin/elasticsearch-users listchencc : superuser這個(gè)命令會(huì)在config下的 users_roles, users文件下生成了role和user信息，用戶為checc, password 為chencc, role為bulid-in role superuser,這個(gè)role默認(rèn)擁有所有的權(quán)限，
參照這里，這里和這里
es配置
## security 相關(guān) 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: 03.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注意兩個(gè)地方都要配置user,password才行。
然后使用 chencc登錄kibana發(fā)現(xiàn)還都是好使的，哈哈哈。
??這也是說明了并不一定絕對(duì)依賴build-in user，他是es的提供的方便，但是實(shí)際使用中肯定還是建議激活的，這些用戶都對(duì)應(yīng)了一些特定的場(chǎng)景，可以更加方便快捷的進(jìn)行權(quán)限劃分。但是在kibana的管理頁面是看不到這個(gè)用戶的存在的，應(yīng)該是無法通過api修改權(quán)限的
但是我們可以將file realm定義的用戶合并到native ,參考這里
但是這個(gè)工具在7.2的時(shí)候已經(jīng)過期了，官方建議是直接使用native realm即可
??同時(shí)，對(duì)于file-realm的使用，es官方的建議是配置一個(gè)高級(jí)別的管理員用戶，在其他用戶都被lock的時(shí)候用戶重置其他用戶。參考這里
3.3 使用kibana創(chuàng)建用戶測(cè)試
??既然chencc可以擁有所有的權(quán)限，不妨索性創(chuàng)建兩個(gè)用戶試試，在kibana的管理頁面創(chuàng)建了一個(gè)role為superuser的用戶chen_test,但是用這個(gè)用戶來登錄kibana的時(shí)候，發(fā)現(xiàn)不行。使用curl訪問的時(shí)候也報(bào)沒有權(quán)限。
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"}]} }??這個(gè)時(shí)候想到有可能額因?yàn)槊總€(gè)es node中顯式的配置了file realm ,導(dǎo)致了native-realm被禁用了（kibana創(chuàng)建的屬于native realm）。所以創(chuàng)建的用戶沒有辦法使用了。參考這里
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 相關(guān) 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訪問，啊啊啊。
如何進(jìn)行帶有user-password的請(qǐng)求參考這里
這里說明了即使關(guān)掉了native,使用kibana和響應(yīng)的api都是還是可以創(chuàng)建用戶的，但是不能正常使用。必須在開啟了native之后這些用戶才是可以使用的。
4.anonymous 用戶的測(cè)試
??es還允許你配置一個(gè)匿名用戶來進(jìn)行訪問，你可以對(duì)這個(gè)用戶進(jìn)行role的設(shè)置，決定了如果一個(gè)訪問沒有攜帶用戶信息的話，就使用配置的匿名用戶來進(jìn)行鑒權(quán)，后面的測(cè)試發(fā)現(xiàn)，如果請(qǐng)求攜帶的用戶權(quán)限不夠，也會(huì)嘗試使用配置的anonymous用戶來代替鑒權(quán)。
4.1 es設(shè)置
## security 相關(guān) 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: true4.2 訪問測(cè)試
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" }可以看到，不帶用戶信息進(jìn)行訪問，也能夠通過，但是假如你攜帶了用戶的信息，但是這個(gè)用戶不存在，或者密碼錯(cuò)誤，這還是會(huì)返回失敗的哦。
5. role中的run as 功能
在es的權(quán)限中中還有一種是run as 權(quán)限，也就是允許你run as另一個(gè)用戶。
這個(gè)時(shí)候，另一個(gè)用戶其實(shí)也就成了一種權(quán)限，類似一個(gè)role一樣。
這個(gè)功能的解釋我看了半天沒有看懂，最后竟然還是借助google翻譯看懂的，大哭。😂
參考這里來解釋一下
一些realms 有進(jìn)行權(quán)限驗(yàn)證的能力，但是可以將role的查找和分配（即授權(quán)）委派給另一個(gè)realm.
當(dāng)然并不是所有的realm都有這種能力，好像PKI的ream不支持作為run as的對(duì)象。
參考這里有進(jìn)一步的說明
下面進(jìn)行ran-as功能測(cè)試
5.1 配置一個(gè)更低權(quán)限的user
POST _security/user/run_user {"password": "run_user","roles": ["beats_system"] }當(dāng)我使用這個(gè)user訪問集群穿件索引的的時(shí)候，發(fā)現(xiàn)是ok的
curl -u 'apm_system:apm_system' -XPUT \ --header "Content-Type:application/json" 10.76.3.145:12200/test05/_doc/2 -d '{"id":5}'??理論上這個(gè)beats_system role是沒有這個(gè)權(quán)限的。然后我又創(chuàng)建了幾個(gè)基礎(chǔ)用戶，發(fā)現(xiàn)也是這種情況，這不科學(xué)啊，搞的我錯(cuò)亂。后來突然想起來，當(dāng)前的es有配置anonymous用戶，是不是有可能沒有權(quán)限的話直接就走這個(gè)anonymous用戶了呢，因?yàn)閍nonymous用戶的權(quán)限是比較高的，關(guān)掉了nanoymous用戶相關(guān)的配置，重啟后果然正常了(就是上面的執(zhí)行會(huì)失敗)。
## 3. 匿名配置 #xpack.security.authc: # anonymous: # username: anonymous_user # roles: superuser,kibana_user # authz_exception: true這個(gè)不知道算不算是坑，在anonymous 相關(guān)的位置沒有看到說明。就這樣吧，哈哈。
進(jìn)行下一步
5.1 給run_user 配置一個(gè)run as 權(quán)限
POST /_security/role/run_as_test {"run_as": ["chencc"] }POST _security/user/run_user {"password": "run_user","roles": ["beats_system","run_as_test"] }發(fā)現(xiàn)還是不行
curl -u 'run_user:run_user' -XPUT --header "Content-Type:application/json" 10.76.3.145:12200/test05/_doc/2 -d '{"id":5}'|jq '.' 135 263 131 263 0 8 41004 1247 --:--:-- --:--:-- --:--:-- 51000 {"status": 403,"error": {"reason": "action [indices:data/write/bulk[s]] is unauthorized for user [run_user]","type": "security_exception","root_cause": [{"reason": "action [indices:data/write/bulk[s]] is unauthorized for user [run_user]","type": "security_exception"}]} }其實(shí)是api使用有點(diǎn)小問題啦，需要使用一個(gè)特殊的http header
這個(gè)header是為了標(biāo)識(shí)你要behalf 那個(gè)用戶，或者是impersonate 哪個(gè)用戶（我只是單純的想要復(fù)習(xí)一下這兩個(gè)單詞😎）
好了，到此run as的功能也介紹的差不多啦。
6.開啟http層面是ssl/tsl加密
??這個(gè)功能之前沒有怎么用過，因?yàn)閭Ρ容^大，需要所有的client都需要配置ssl相關(guān)的配置才能訪問，比如kibana,logstash,filebeat,外部的exporter等等。這里是探索，就用一下試試吧。在已經(jīng)完成了transport層面的ssl配置之后,在http層面的配置在es上相對(duì)還是很簡(jiǎn)單的。
elasticsearch.yml增加以下配置
## http請(qǐng)求加密 xpack.security.http.ssl.enabled: true xpack.security.http.ssl.keystore.path: certs/elastic-certificates.p12 xpack.security.http.ssl.truststore.path: certs/elastic-certificates.p12 xpack.security.http.ssl.client_authentication: none第四個(gè)配置沒有看出來有啥用,就是配置了服務(wù)端是否需要客戶端的證書。
這個(gè)配置完后進(jìn)行重啟，使用curl請(qǐng)求卻訪問不通了，看了服務(wù)器有很多報(bào)錯(cuò)日志
當(dāng)我時(shí)使用
curl -u 'chencc:chencc' http://10.76.0.98:12200 |jq '.'curl: (52) Empty reply from server在瀏覽器端訪問http://10.76.0.98:12200也不行了，kibana自然也是報(bào)錯(cuò)
搞的我一度以為es集群起不起來，掛掉了，但是當(dāng)我使用 netstat -tupln,又看到了對(duì)應(yīng)的端口
后面想到是不是應(yīng)該用https訪問，在瀏覽器端改成https之后，信任了私有證書之后，終于可以正常訪問了。然后是curl請(qǐng)求，忽略證書的校驗(yàn)，改成https訪問,success!
總結(jié)
以上是生活随笔為你收集整理的01.elasticsearch-security_es鉴权机制的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 02.elasticsearch-mon
- 下一篇： 01.analyzer简介及char_f