我們的系統(tǒng)安裝了 X-Pack 用于控制訪(fǎng)問(wèn)權(quán)限,他可以通過(guò)設(shè)定 Roles,然后建立用戶(hù)關(guān)聯(lián)這些 Roles 來(lái)完成一個(gè)用戶(hù)的指定權(quán)限設(shè)定囤萤。
我們通過(guò)一個(gè) AWS Lambda 程序來(lái)備份指定日期的 Index 文件到 AWS S3 系統(tǒng)當(dāng)中,并且處理所有 Index Aliases 內(nèi)容。這樣我們就需要分配一個(gè) Cluster 中的 Manager 權(quán)限滞磺,并且對(duì)指定的 Indices 給出 Manager 權(quán)限。
但是通過(guò)官方 Security Privileges 說(shuō)明可以看到莱褒,這兩個(gè) manager 權(quán)限實(shí)在都太大了击困。這個(gè)用戶(hù)分配給 Lambda 程序后,用戶(hù)名口令相當(dāng)于是明文存在的广凸。會(huì)對(duì)系統(tǒng)產(chǎn)生較高的風(fēng)險(xiǎn)阅茶。但是整個(gè)系統(tǒng)中 Build-In 的權(quán)限設(shè)定比較少。所以需要對(duì)這個(gè)賬戶(hù)的 Role 進(jìn)行更細(xì)顆粒度的限定谅海。
X-Pack Security 結(jié)構(gòu)
在這個(gè)系統(tǒng)中脸哀,權(quán)限管理是下面這么個(gè)層次結(jié)構(gòu):
Privileges --> Roles --> User
其中 Privileges 分為針對(duì)整個(gè) Cluster 或者針對(duì)特定的 Indices 設(shè)定。
如果能夠知道更詳細(xì)的 Privileges 列表扭吁,那么將其通過(guò) _xpack/security/role API 就可以創(chuàng)建一個(gè)自定義的 Roles撞蜂,如何創(chuàng)建請(qǐng)參考 Defining Roles 的說(shuō)明。
但是問(wèn)題是查遍官方文檔侥袜,沒(méi)有任何地方對(duì)系統(tǒng)中都提供了什么 Privileges 有列表蝌诡。官方給出的答復(fù)是并不公開(kāi)提供這個(gè)列表內(nèi)容。
Privileges 列表
在老版本的 Elasticsearch 2.2 中找到了 Action Level Privileges 的列表枫吧,這個(gè)在 2.3浦旱、2.4、5.x 的文檔中都不在存在了九杂。
我們測(cè)試過(guò)部分的 Cluster:admin 功能設(shè)定颁湖,在 5.6.3 的系統(tǒng)中是能夠正常工作和限定的宣蠕。對(duì)于 Indices 的部分,因?yàn)槲覀儗?duì) Indices 的控制沒(méi)有需求甥捺,就沒(méi)多看了抢蚀。應(yīng)該這個(gè)部分都是正常的,就是可能有缺少而已涎永。
列表的規(guī)則很簡(jiǎn)單思币,第一個(gè)標(biāo)記的是針對(duì)哪個(gè)進(jìn)行權(quán)限設(shè)定,Cluster 或者 Indices羡微,第二列表示了是用于管理還是數(shù)據(jù)訪(fǎng)問(wèn)谷饿,也就是 admin 或者 data,然后后面的內(nèi)容跟具體操作的 RESTful API 的路徑基本一致妈倔。
按照我們的需求:執(zhí)行 snapshot 并且對(duì) alias 進(jìn)行一些管理博投,我們?cè)O(shè)置了兩個(gè)自定義 Roles:
POST _xpack/security/role/snap-creator
{
"cluster": [
"cluster:admin/snapshot/status",
"cluster:admin/snapshot/create"
]
}
POST _xpack/security/role/alias-manager
{
"indices":[
{
"names": ["metric-*"],
"privileges": [
"indices:admin/aliases",
"indices:admin/get"
]
}
]
}
其中 indices:admin/get
權(quán)限若不設(shè)定, _aliases 指令無(wú)法執(zhí)行盯蝴,應(yīng)該是拿不到 Indices 的列表導(dǎo)致的毅哗。但是并不知道這個(gè) indices:admin/get
權(quán)限的具體范疇,因?yàn)槲覀儗?duì)數(shù)據(jù)讀取沒(méi)有那么大的安全控制需要捧挺,就沒(méi)有多加嘗試虑绵。
如何知道我的指令需要什么權(quán)限?
在測(cè)試我們的 Role 處理的過(guò)程中闽烙,突然注意到:如果沒(méi)有權(quán)限執(zhí)行一個(gè)操作的時(shí)候翅睛,Elasticsearch 自己就會(huì)告訴你他需要哪個(gè) Privileges 的定義。
curl -XGET -u test-rule:123456 https://localhost:9200/metric-\*/_aliases
{
"error": {
"root_cause": [
{
"type": "security_exception",
"reason": "action [indices:admin/get] is unauthorized for user [test-rule]"
}
],
"type": "security_exception",
"reason": "action [indices:admin/get] is unauthorized for user [test-rule]"
},
"status": 403
}
上面 [indices:admin/get]
的提示內(nèi)容黑竞,就是我們應(yīng)該設(shè)定的 Privileges 的內(nèi)容捕发。我平時(shí)都是在 Kibana Console 中用 Supper-User 做操作,從來(lái)沒(méi)有見(jiàn)過(guò)這個(gè)很魂,真是坑啊扎酷。??
大家如果在權(quán)限設(shè)定上需要更加細(xì)節(jié)的權(quán)限控制,完全可以 curl
指令去測(cè)試一下遏匆,看看給出哪些 Privileges 能夠讓他正常工作法挨。
不過(guò)要特別注意,官方特別強(qiáng)調(diào):Although rarely needed 幅聘,并且我們咨詢(xún)過(guò)他們的 Support凡纳,他們也說(shuō)如果不是特別必須,建議我們不要這么設(shè)定 Privileges 的內(nèi)容喊暖,還是使用他們的 Build-In Privileges惫企。
不過(guò)實(shí)在想不明白為什么官方要這么做撕瞧。就看他們一個(gè) Manager 的描述:
All monitor privileges plus index administration (aliases, analyze, cache clear, close, delete, exists, flush, mapping, open, force merge, refresh, settings, search shards, templates, validate).
為了一個(gè) Alias 操作陵叽,給這個(gè)權(quán)限出去狞尔,實(shí)在是能?chē)標(biāo)牢摇?/p>
其他參考
在找 X-Pack Security 資料的過(guò)程中找到了 Search Guard 這么一個(gè) Opensource 軟件,從媒體報(bào)道和他自己的說(shuō)明上看巩掺,完全可以替代 X-Pack 的使用偏序。
他的相關(guān)文檔在一個(gè)獨(dú)立的 Github Repository 里面。這個(gè)可以看看胖替,整個(gè)的工作邏輯跟 X-Pack Security 應(yīng)該是非常類(lèi)似的研儒。
我們直接在 Elastic Cloud 上啟動(dòng)了 X-Pack 就沒(méi)有嘗試這個(gè)東西。