01.elasticsearch-security_es鉴权机制
文章目錄
- 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開啟的操作流程，這篇文章的主要是為了搞清楚這些流程中的每一步是否必要，有什么含義。先總結官方步驟如下
這個會開啟security設置，也就開啟了node之間使用ssl和基于用戶的訪問模式
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.p123.訪問測試
這個時候集群的啟動是正常的，但是使用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"}]} }發現需要用戶信息，必須使用用戶才能夠正常的訪問。
使用默認的用戶信息
訪問發現也是不行的，通過文檔查找知道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: 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注意兩個地方都要配置user,password才行。
然后使用 chencc登錄kibana發現還都是好使的，哈哈哈。
??這也是說明了并不一定絕對依賴build-in user，他是es的提供的方便，但是實際使用中肯定還是建議激活的，這些用戶都對應了一些特定的場景，可以更加方便快捷的進行權限劃分。但是在kibana的管理頁面是看不到這個用戶的存在的，應該是無法通過api修改權限的
但是我們可以將file realm定義的用戶合并到native ,參考這里
但是這個工具在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的請求參考這里
這里說明了即使關掉了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: true4.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翻譯看懂的，大哭。😂
參考這里來解釋一下
一些realms 有進行權限驗證的能力，但是可以將role的查找和分配（即授權）委派給另一個realm.
當然并不是所有的realm都有這種能力，好像PKI的ream不支持作為run as的對象。
參考這里有進一步的說明
下面進行ran-as功能測試
5.1 配置一個更低權限的user
POST _security/user/run_user {"password": "run_user","roles": ["beats_system"] }當我使用這個user訪問集群穿件索引的的時候，發現是ok的
curl -u 'apm_system:apm_system' -XPUT \ --header "Content-Type:application/json" 10.76.3.145:12200/test05/_doc/2 -d '{"id":5}'??理論上這個beats_system role是沒有這個權限的。然后我又創建了幾個基礎用戶，發現也是這種情況，這不科學啊，搞的我錯亂。后來突然想起來，當前的es有配置anonymous用戶，是不是有可能沒有權限的話直接就走這個anonymous用戶了呢，因為anonymous用戶的權限是比較高的，關掉了nanoymous用戶相關的配置，重啟后果然正常了(就是上面的執行會失敗)。
## 3. 匿名配置 #xpack.security.authc: # anonymous: # username: anonymous_user # roles: superuser,kibana_user # authz_exception: true這個不知道算不算是坑，在anonymous 相關的位置沒有看到說明。就這樣吧，哈哈。
進行下一步
5.1 給run_user 配置一個run as 權限
POST /_security/role/run_as_test {"run_as": ["chencc"] }POST _security/user/run_user {"password": "run_user","roles": ["beats_system","run_as_test"] }發現還是不行
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"}]} }其實是api使用有點小問題啦，需要使用一個特殊的http header
這個header是為了標識你要behalf 那個用戶，或者是impersonate 哪個用戶（我只是單純的想要復習一下這兩個單詞😎）
好了，到此run as的功能也介紹的差不多啦。
6.開啟http層面是ssl/tsl加密
??這個功能之前沒有怎么用過，因為傷害比較大，需要所有的client都需要配置ssl相關的配置才能訪問，比如kibana,logstash,filebeat,外部的exporter等等。這里是探索，就用一下試試吧。在已經完成了transport層面的ssl配置之后,在http層面的配置在es上相對還是很簡單的。
elasticsearch.yml增加以下配置
## http請求加密 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第四個配置沒有看出來有啥用,就是配置了服務端是否需要客戶端的證書。
這個配置完后進行重啟，使用curl請求卻訪問不通了，看了服務器有很多報錯日志
當我時使用
curl -u 'chencc:chencc' http://10.76.0.98:12200 |jq '.'curl: (52) Empty reply from server在瀏覽器端訪問http://10.76.0.98:12200也不行了，kibana自然也是報錯
搞的我一度以為es集群起不起來，掛掉了，但是當我使用 netstat -tupln,又看到了對應的端口
后面想到是不是應該用https訪問，在瀏覽器端改成https之后，信任了私有證書之后，終于可以正常訪問了。然后是curl請求，忽略證書的校驗，改成https訪問,success!
總結
以上是生活随笔為你收集整理的01.elasticsearch-security_es鉴权机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 02.elasticsearch-mon
- 下一篇： 01.analyzer简介及char_f