vault文檔(2)——內部結構(待續)

1. 概述

該部分會通過vault的功能、架構和安全特性去介紹vault的內部結構和技術細節。

注意:如果你只是爲了使用Vault或對它的內部結構不感興趣,那可跳過該部分。如果要對Vault進行管理,建議閱讀一下該部分。

2. 架構

vault是一個由許多部分組成的複雜系統。該頁面幫助用戶和開發者通過概念模型去了解它的運作方式。
高級主題:該頁面會介紹vault的技術細節。就算你不理解這些知識,也能高效地使用vault。該部分文檔只是通過一種無需閱讀源代碼的方式去幫助那些想了解該知識點的同學而建立。如果你需要對vault進行管理,因vault在環境中的重要性我們建議你去學習一下該部分知識。

2.1 詞彙表

在對架構進行介紹之前,我們會提供一份詞彙表去幫助你們理清將要被介紹的內容:

  • 存儲後端(Storage Backend) - 存儲後端能夠持久化地存儲加密數據。後端不會被vault信任,只是爲了提供持久化保存的功能。啓動vault服務的時候該存儲後端會被加載。
  • 屏障(Barrier)- 這個屏障就相當於vault的保護殼。流經vault和存儲後端的所有數據都會經過這個屏障。它會確保只有加密的數據會被寫出,並在傳輸的過程中對數據進行驗證和解密。就像銀行金庫一樣,要取出裏面的東西先得解鎖。
  • 密鑰引擎(Secrets Engine)- 密鑰引擎負責管理密鑰。像“kv”這類簡單密鑰引擎在查詢的時候會簡單地返回相同的密鑰。部分密鑰引擎支持通過策略去在你每次查詢的時候動態生成密鑰。這能讓vault對每一個獨立的密約都能進行細粒度的撤權與策略的更新。例如:可配置一個“web”策略到MySQL密鑰引擎中。當“web”的密鑰被讀取,一對擁有有限權限的新的MySQL用戶名/密碼將會爲web服務器而生成。
  • 審計設備(Audit Device)- 審計設備負責管理審計記錄信息。流入和流出vault的數據都會經過它。它提供了一種簡單的方式去讓vault與多個審計系統進行集成。
  • 認證方法(Auth Method)- 它用來對正在連接到vault的用戶或應用進行認證。一旦認證成功,它會返回將要被使用的應用策略列表信息。vault接受經過身份驗證的用戶並返回可用於將來請求的客戶端令牌。例如:userpass認證方法會使用用戶名和密碼去對用戶進行認證。而github認證方法則通過GitHub去進行認證。
  • 客戶端令牌(Client Token)- 客戶端令牌(又叫“Vault令牌”)相當於網站裏面的一個會話cookie。一旦一個用戶認證之後,Vault會返回一個將來請求需要使用的客戶端令牌。Vault會通過該令牌去識別身份並執行可用的ACL(訪問控制列表)策略。該token放在HTTP的頭部中。
  • 密鑰(Secret)- 密鑰是Vault能返回包含機密或加密數據的關鍵因素。但並不是Vault返回的所有數據都是加密的,像系統配置,狀態信息或者策略是不會被加密的。密鑰總是有一個租期。這意味着一個密鑰不能無限期地使用。Vault會在租期結束的時候撤回對應的密鑰,管理人員也可以人工干預密鑰的租期結束時間。這份Vault與客戶端之間的合同是至關重要的,因爲它允許在沒有人工干預的情況下更改密鑰和策略。
  • 服務(Server)- Vault需要一臺可長時間運行的服務器。該Vault服務器提供一個能提供客戶端與之進行通信、管理全部密鑰引擎的相互通信、ACL執行、密鑰租期收回功能的API。使基於服務器的體系結構將客戶端與安全密鑰和策略分離,實現集中審計日誌記錄並簡化操作員的管理。

2.2 體系結構

從體系結構看,Vault看起來像下面這張圖:
Vault結構
我們來對這張圖片進行分解。安全屏障內部或外部的組件明顯分離。只有存儲後端和HTTP API在外面,其他的全部組件都在屏障的裏面。

存儲後端是不被信任的,只是用作將加密的數據進行持久化處理。當Vault服務啓動時,必須要提供一個存儲後端給Vault,這樣之前保存的數據才能在重啓後仍能訪問到。同樣地,HTTP API也要提供這樣客戶端才能與它進行交流。

一旦啓動完畢,Vault時處理一個密封的狀態。要對它進行開封才能進行其他操作。可通過提供開封鑰匙來完成開封。當Vault初始化完畢後,它會生成一把能用來保護數據的加密鑰匙。該鑰匙會被一把主鑰匙保護着。默認情況下,Vault會使用一種被稱爲Shamir的祕密共享算法去將主鑰匙分成5把小鑰匙,要重建主鑰匙必須要使用其中的3把去完成。
Shamir's secret sharing algorithm
鑰匙拆分的數量和最小組成主鑰匙數量都可進行自定義。可通過禁用來不使用Shamir的算法進行處理,這樣就可直接使用主鑰匙來進行開封。一旦Vault獲取到加密鑰匙,就能夠對存儲在後端存儲的數據進行解密,然後會進入到開封狀態。一旦開封后,Vault會讀取全部的審計設備、加密方法和密鑰引擎。

這些審計設備、加密方法和密鑰引擎的配置必須要存儲到Vault中因爲它們是極爲重要的。只有攜帶正確權限的用戶才能去修改它們,這意味着它們不能被分配到屏障之外。通過Vault去存儲它們,使得對它們的任何更改都受到ACL系統的保護並被審計日誌進行記錄。

Vault被開封之後,HTTP API到內核的數據可被正確請求。內核用來管理流經系統的請求,執行ACL並確保審計記錄的完成。

當一個客戶端首次連接到Vault,它需要進行認證。Vault提供配置好的認證方法,爲所使用的身份驗證機制提供靈活性。操作者可使用人性化的認證機制,如用戶名/密碼或GitHub認證方式。與此同時,應用也可使用公鑰/私鑰或令牌去進行認證。一個流經內核的認證請求,會進入認證方法,該方法會判斷該請求是否合法並返回與之相關的策略列表。

策略只是一個已命名好的ACL規則。例如,“root”策略是內建的,它允許訪問全部資源。你可以爲每一個路徑創建指定名字的細粒度控制策略。Vault僅以白名單模式運行,這表明除策略允許外的操作都不允許執行。因爲一個用戶可擁有多個策略與之關聯,那麼只要策略中的其中一個允許執行那麼該操作就是可行的。策略被一個內部策略存儲容器保存和管理着。這個內部存儲容器會通過系統後端進行操作,它總是被掛載在sys/目錄下。

一旦認證完成並且一個認證方法提供了一個適用的策略集合,一個新的客戶端令牌會生成,然後它會受令牌存儲管理。該客戶端令牌會發回給客戶端,然後會被用作未來的請求。這就類似於一個用戶登陸網站之後所收到的cookie。該客戶端令牌可以根據認證方法配置過期時間。這意味着你需要去週期性地更新它避免令牌失活。

一旦認證過後,生成的請求會提供客戶端令牌。這個令牌會用來驗證客戶端已被授權和用來讀取相關的策略。這些策略會用來授權客戶端請求。授權完畢後,請求會被路由到密鑰引擎,這些請求會根據密鑰引擎的類型去進行相應處理。如果密鑰引擎返回了一個密鑰,該內核會用使用一個租約管理器去註冊這個密鑰,並分配給密鑰一個租約ID。該租約ID可被客戶端用來刷新和收回密鑰。如果客戶端允許租約過期,那麼租約管理器會自動收回該密鑰。

內核會把請求和響應的日誌傳輸到審計中間件,該中間件會將請求傳遞給所有已配置的審計設備。除了請求流之外,Vault內核也會進行其他的一些後臺活動。租約管理是關鍵點,因爲它允許使得過期的客戶端令牌或密鑰能被自動回收。此外,Vault通過使用回滾管理器進行預寫日誌記錄來處理某些部分故障情況。這會在內核中透明地管理,用戶對此是不可見的。

2.3 深入瞭解

這是對Vault體系結構的簡要概述。接下來會對每個子系統進行更爲詳細的介紹。

有關其他詳細信息,請查閱代碼,在IRC中詢問或聯繫郵件列表。

待續。。。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章