ranger 和kerberos 一般有用看1 速

十一vs十一發表於2024-03-16

再說ranger之前需要明白一下大資料的安全體系的整體介紹，安全體系其實也就是許可權可控，先說說許可權：許可權管理的目標，絕對不是簡單的在技術層面建立起使用者，密碼和許可權點的對映關係這麼簡單的事，更重要的是要從流程合理性，業務隔離，實施代價，可執行性等方面進行考慮。單方面強調安全，結果往往並不理想。重要的透過適度的安全管理手段，降低業務誤操作的風險，結合業務流程和系統互動設計，實現業務的合理分隔，提高工作效率，同時將許可權管理工作分級授權下放到業務負責人和團隊，實現業務自治管理，明晰責任歸屬，讓許可權管理充分發揮其促進業務健康安全發展的作用，而不是相反。所以在實現過程中，要爭取在可接受的安全範圍內，保持相對較低的開發，管理和維護代價，做到真正有效的實施，否則再完美的系統也會因為人的因素而大打折扣。舉個例子，比如美國的核彈發射密碼箱，一天24小時由將軍以上級別的專人隨身攜帶看管，安全措施可謂嚴格了吧，但據坊間謠言傳聞，由於害怕複雜的密碼總統記不住，核彈發射安全箱的密碼一度是8個0...

大資料的安全管控

許可權的管控，歷來是大資料平臺中最讓人頭疼的問題之一。管得嚴了，業務不流暢，使用者不開心，放得寬了，安全沒有底，你能放心？而且大資料平臺元件，服務眾多；架構，流程複雜，有時候，就是你想管，也未必能管得起來。

涉及到具體的技術方案層面，Kerberos，LDAP，Sentry，Ranger，Quota，ACL，包括各個元件自己的許可權管控方案，這些話題，不是一小節的篇幅能夠覆蓋的，所以，不打算在這裡詳細討論各種技術方案。

許可權的管控，做多少，怎麼做，花多少代價，取決於你的目標出發點，很多公司整合開發環境的許可權管控目標：是對使用者常規的業務行為範圍進行限定，敏感資料的控制固然是一方面，但更重要的是對業務邏輯和流程的約束，透過減少使用者不必要的許可權，減小受害面，降低可能的業務風險，同時也便於明確使用者的權責歸屬關係。

所以，還是讓我們來談一下許可權管控的目標。我們的許可權管控目標，是防君子不防小人。此話怎講？許可權管控，大家都知道，有兩個步驟：認證（authentication）和授權（authorization）。前者鑑定身份，後者根據身份賦予許可權。

常見開源方案

許可權管理相關工作可以分為兩部分內容：

一、管理使用者身份，也就是使用者身份認證（Authentication）

二、使用者身份和許可權的對映關係管理，也就是授權（Authorization）

前者，使用者身份認證這一環節，在Hadoop生態系中常見的開源解決方案是 Kerberos+LDAP，而後者授權環節，常見的解決方案有Ranger，Sentry等，此外還有像knox這種走Gateway代理服務的方案。

下面簡單介紹一下這些開源專案，目的不是為了講解這些方案的實現原理，而是從整體架構流程的角度來看看他們的目標問題和解決思想，以及適用場景等，這樣當你在選擇或者開發適合自己平臺的許可權管理方案時，也可以做到知其然，知其所以然。

至於Hadoop生態系的各個元件比如HDFS/Hive/HBase自身的許可權管理模型，針對的是單一的具體元件，也是許可權管控體系中的重要組成部分，但限於篇幅原因，本文就不加以討論了。

kerberos

Kerberos是Hadoop生態系中應用最廣的集中式統一使用者認證管理框架。

工作流程簡單的來說，就是提供一個集中式的身份驗證伺服器，各種後臺服務並不直接認證使用者的身份，而是透過Kerberos這個第三方服務來認證。使用者的身份和秘碼資訊在Kerberos服務框架中統一管理。這樣各種後臺服務就不需要自己管理這些資訊並進行認證了，使用者也不需要在多個系統上登記自己的身份和密碼資訊。

原理使用者的身份首先透過密碼向Kerberos伺服器進行驗證，驗證後的有效性會在使用者本地保留一段時間，這樣不要使用者每次連線某個後臺服務時都需要輸入密碼。然後，使用者向Kerberos申請具體服務的服務秘鑰，Kerberos會把連線服務所需資訊和使用者自身的資訊加密返回給使用者，而這裡面使用者自身資訊進一步是用對應的後臺服務的秘鑰進行加密的，由於這個後臺服務的秘鑰使用者並不知曉，所以使用者也就不能偽裝或篡改這個資訊。然後，使用者將這部分資訊轉發給具體的後臺伺服器，後臺伺服器接收到這個資訊後，用自己的秘鑰解密得到經過Kerberos服務認證過的使用者資訊，再和傳送給他這個資訊的使用者進行比較，如果一致，就可以認為使用者的身份是真實的，可以為其服務。

核心思想 Kerberos最核心的思想是基於秘鑰的共識，有且只有中心伺服器知道所有的使用者和服務的秘鑰資訊，如果你信任中心伺服器，那麼你就可以信任中心伺服器給出的認證結果。

很重要的一點從流程上來說，Kerberos不光驗證的使用者真實性，實際上也驗證了後臺服務的真實性，所以他的身份認證是雙向認證，後臺服務同樣是透過使用者，密碼的形式登記到系統中的，避免惡意偽裝的釣魚服務騙取使用者資訊的可能性。

應用Kerberos的難點 Kerberos從原理上來說很健全，但是實現和實施起來是很繁瑣的。 1、首先所有的後臺服務必須針對性的接入Kerberos的框架，其次所有的客戶端也必須進行適配，如果具體的後臺服務提供對應的客戶端接入封裝SDK自然OK，如果沒有，客戶端還需要自己改造以適配Kerberos的認證流程。 2、其次，使用者身份的認證要真正落地，就需要實現業務全鏈路的完整認證和傳遞。如果是客戶端直連單個服務，問題並不大，但是在大資料平臺服務分層代理，叢集多節點部署的場景下，需要做使用者身份認證的鏈路串聯就沒那麼簡單了。 3、舉個例子，如果使用者透過開發平臺提交一個Hive指令碼任務，該任務首先被開發平臺提交給排程系統，再由排程系統提交給Hive Server，Hive Server再提交到hadoop叢集上執行。那麼使用者資訊就可能要透過開發平臺-->排程系統Master節點--->排程系統Worker節點-->Hive Server-->Hadoop 這幾個環節進行傳遞，每個上游元件都需要向下遊元件進行使用者身份認證工作。 4、就算到了具體的後臺服務內部。比如在Hadoop叢集上執行的一個MR任務，這個認證關係鏈還需要繼續傳遞下去。首先客戶端向Yarn的RM節點提交任務，客戶端需要和RM節點雙向驗證身份，然後RM將任務分配給NM節點啟動執行，RM就需要把使用者身份資訊傳給NM（因為NM節點上啟動的任務會需要以使用者的身份去讀取HDFS資料）在NM節點上的任務以使用者的身份連線HDFS NameNode獲取後設資料以後，下一步還需要從HDFS Datanode節點讀取資料，也就再次需要驗證使用者身份資訊。上述的每個環節如果要支援基於Kerberos的身份驗證，要麼要正確處理秘鑰的傳遞，要麼要實現使用者的代理機制。而這兩者，實施起來難度都不小，也會帶來一些業務流程方面的約束。 5、雪上加霜的是，這個過程中，還要考慮身份驗證的超時問題，秘鑰資訊的保管和保密問題等等，比如MR任務跑到一半秘鑰或Token過期了該怎麼辦，總不能中斷任務吧？所以一套完整的鏈路實現起來絕非易事，這也是很多開源系統遲遲沒有能夠支援Kerberos的原因之一，而自己要在上層業務鏈路上完整的傳遞使用者身份資訊，也會遇到同樣的問題。 6、最後是效能問題，集中式管理在某種程度上意味著單點，如果每次RPC請求都要完整的走完Kerberos使用者認證的流程，響應延遲，併發和吞吐能力都會是個比較大的問題，所以比如Hadoop的實現，內部採用了各種Token和cache機制來減少對Kerberos服務的請求和依賴，並不是每一個環節步驟都透過Kerberos進行驗證。

小結總體來說，Kerberos是當前最有效最完善的統一身份認證框架，但是如果真的要全面實施，代價也很高，而從安全的角度來考慮，如果真的要防止惡意破壞的行為，在整個生產環境流程中，能被突破的環節其實也很多，光上Kerberos並不意味著就解決了問題，所以各大網際網路公司用還是不用Kerberos，大家並沒有一致的做法，即使All in Kerberos的公司，我敢說，除非完全不做服務化的工作，否則，整體鏈路方面也一定存在很多並不那麼Kerberos的環節；）

最後，使用者身份認證只是許可權管理環節中很小的一部分，雖然技術難度大，但是從實際影響來看，合理的許可權模型和規範的管理流程，通常才是資料安全的關鍵所在。所以，上不上Kerberos需要結合你的實際場景和安全需求加以考量。

Sentry和Ranger

Sentry和Ranger的目標都是統一的授權管理框架／平臺，不光目標，這兩個專案在思想和架構方面也大同小異，那麼為什麼會有兩套如此類似的系統？當然是因為Cloudera和Hortonworks兩家互相不鳥，必須各搞一套唄，目前看起來，Sentry借CDH使用者基數大的東風，普通使用者比較容易接受，但Ranger在功能完整性方面似乎略微佔點上風。

相比使用者身份認證，授權這件事情和具體服務的業務邏輯關聯性就大多了，如果是純SQL互動的系統，透過解析指令碼等方式，從外部去管理授權行為有時是可行的，其它情況，通常都要侵入到具體服務的內部邏輯中才有可能實現許可權的控制邏輯。

所以Sentry和Ranger都是透過Hook具體後臺服務的流程框架，深度侵入程式碼，新增授權驗證邏輯的方式來實現許可權管控的，只不過具體的許可權管理相關資料的儲存，查詢，管理工作實際是對接到外部獨立的系統中承接實現的，進而實現各種儲存計算叢集許可權的統一管理。

要Hook具體後臺服務的流程框架，最理想的是原系統本身就提供外掛式的許可權管理方案可供擴充套件，否則就需要對原系統進行針對性的改造，另外各個系統自身既有的許可權模型也未必能滿足或匹配Sentry和Ranger所定義的統一許可權管理模型，是否能改造本身就是個問題。

加上許可權驗證流程透過查詢外部服務實現，因此在許可權的同步，對原系統的效能影響等方面常常也需要小心處理或者針對性的最佳化。因此，統一的授權管理平臺這一目標也是一個浩大的工程。所以至今無論Sentry還是Ranger都未能全面覆蓋Hadoop生態系中常見的計算儲存框架。

小結總體來說，授權這件事，Hadoop生態系中的各個元件往往會有自己獨立的解決方案，但是各自方案之間的連通性並不好。而統一的授權管理框架／平臺的目標就是解決這個問題，但它們當前也不算很成熟，特別是在開放性和定製性上，往往也有一定侷限性。

當然，要用一個框架徹底打通所有元件的許可權管理工作，除了外掛化，其它其實也沒有特別好的方式，而外掛化自然需要框架和具體元件的雙向合作努力。只能說就當前發展階段而言，這一整套方案尚未足夠成熟，沒到完美的程度，也沒有事實統一的標準。所以無論是Sentry還是Ranger，當前的實現如果剛好適合你的需求自然最好，如果不適合，那還需要自己再想辦法，且看他們將來的發展吧。

但是先對來說好多公司選擇了ranger，原因如下：

多元件支援(HDFS,HBASE,HIVE,YARN,KAFKA,STORM)，基本覆蓋我們現有技術棧的元件
支援審計日誌，可以很好的查詢到哪個使用者在哪臺機器上提交的任務明細，方便問題排查反饋
擁有自己的使用者體系，可以去除kerberos使用者體系，方便和其他系統整合，同時提供各類介面可以呼叫
綜上：我們考慮到和開放平臺的整合，以及我們的技術棧和叢集操作的審計等幾個問題最終選用了apache ranger

Knox

最後來說一下Knox專案，它的思想是透過對Hadoop生態系的元件提供GateWay的形式來加強安全管控，你可以近似的認為他就是一個Rest／HTTP的服務代理/防火牆。

所有使用者對叢集的Rest／HTTP請求都透過Knox代理轉發，既然是代理，那麼就可以在轉發的過程中做一些身份認證，許可權驗證管理的工作，因為只針對Rest／HTTP服務，所以他並不是一個完整的許可權管理框架

使用Gateway的模式有很大的侷限性，比如單點，效能，流程等等，不過對於Rest／HTTP的場景倒也算是匹配。它的優勢是透過收攏Hadoop相關服務的入口，可以隱藏Hadoop叢集的拓撲邏輯，另外，對於自身不支援許可權認證管理的服務，透過Gateway也能自行疊加一層許可權管控。

常見的許可權模型

開源專案中常見的許可權模型概念：RBAC ／ ACL ／ POSIX ／ SQL Standard 首先來看RBAC模型，RBAC從標準規範的角度來看，絕對是一個複雜的標準，但是實際情況下，各種開源系統在討論RBAC的時候，通常重點指的就是許可權和使用者之間需要透過角色的概念進行一次二次對映，目的是為了對同類許可權或同類使用者進行歸類，減少需要維護的對映關係的數量。至於RBAC理論層面上各種層級的約束，條件，規範等等，其實談得很少。

而在其它模型中，也或多或少有組/角色的概念，只是比如：組的涵蓋範圍，是否允許存在多重歸屬，能否交叉，能否巢狀，是否允許使用者和許可權直接掛鉤等具體規則上有所區別。不過基本上，如果你要宣稱自己是一個RBAC模型的話，那麼基本上還是要重點強調角色模型和對映關係的建設。而在其它模型中，組/角色的概念相對來說可能並沒有那麼突出或者重要。

然後談POSIX的許可權模型，談這個，當然是因為HDFS的檔案許可權模型，很長一段時間以來，只支援POSIX標準檔案的許可權管理模型，即一個檔案對應一個OWNER和一個GROUP，對OWNER和GROUP以及其它使用者配置RWAC這樣的讀寫透過管理等許可權。

POSIX模型很直白，很容易理解，實現也簡單，但POSIX模型最大的問題是檔案的共享很難處理。因為要將許可權賦予一撥人，只能透過單一固定的組的概念，你無法針對不同的人群和不同的檔案進行分組授權，所以很難做到精細化的授權管理。

為了解決許可權多對映精細管理問題，HDFS又引入了ACL模型，Access Control List，故名思意，就是針對訪問物件，有一個授權列表。那麼對不同物件給不同使用者賦予不同的許可權也就不成問題了。當然，HDFS的ACL模型也不是範本，事實上各種系統中所謂的ACL模型，具體設計都不盡相同，唯一可能共通的地方就是：對訪問物件賦予一個授權列表這個概念，而不是像POSIX這樣固定分類的授權模式。

ACL模型理論上看起來很理想，但在HDFS叢集這個具體場景中，麻煩的地方在於如果叢集規模比較大，授權列表的數量可能是海量的，效能，空間和效率上都可能成為問題，而事實上，ACL物件精細化的管理也並不那麼容易。當然這些也並不能算是ACL模型自身的問題，更多的是具體的實現和上層業務規劃方面的問題。

最後所謂的SQL標準的許可權模型，從模型的角度來說和ACL模型並沒有什麼本質的區別，只不過是在類SQL語法的系統中，模仿了Mysql等傳統資料庫中標準的授權語法來與使用者進行互動。具體的實現例子，比如Hive Server2中支援的SQL標準授權模型。

再比較一下底層統一許可權管控平臺和基於開發平臺進行邊界許可權管控的優缺點首先，Ranger等方案，主要依託大資料元件自身的方案，Hook進執行流程中，所以管控得比較徹底，而開發平臺邊界許可權管控，前提是需要收攏使用入口，所以論絕對安全性，如果入口收不住，那麼不如前者來得徹底。不過通常來說，為使用者提供統一的服務入口，不光是安全的需要，也是開發平臺提高自身服務化程度和易用性的必要條件。

其次，底層許可權統一管控平臺，因為依託的是大資料元件自身的方案，並不收攏使用者互動入口，所以身份認證環節還是需要依託類似Kerberos這樣的系統來完成。而開發平臺服務方式，收攏了入口，就可以用比較簡單方式自行完成身份認證，如前所述，相比涉及到三方互動的分散式身份認證機制，通常實現代價會更低一些。

再次，大資料元件自身的許可權方案，許可權驗證環節通常發生在任務實際執行的過程中，所以流程上基本都是在沒有許可權的時候丟擲一個異常或返回錯誤，因此不太可能根據業務場景做更加靈活的處理。

而開發平臺服務方式，許可權的驗證如果可以做到在執行前階段（比如透過語法分析獲得）進行，那麼流程上就可以靈活很多，可以結合業務相關資訊提供更豐富的調控手段。

例如，業務開發過程中，在程式碼編輯或儲存時就可以進行相關許可權驗證和提示，避免在半夜任務實際執行時才發現問題。也可以定期批次審計指令碼任務，或者根據業務重要程度對缺乏許可權的情況進行區別對待：提示，警告，阻斷等等。簡單的說，就是你想怎麼做就怎麼做。而Ranger等基於底層元件進行Hook的許可權架構方案，一來沒有相關業務資訊無法做出類似決策，二來考慮通用性，很多平臺環境相關業務邏輯不可能也不適合繫結進來。

當然，這兩種方案並不是互斥的，如何定義你的產品，如何拆分各種需求，對你選擇許可權管控方案也有很大的影響。更常見的情況是，你會需要一個混合體，取長補短，彌補各自的不足之處。

ranger簡介

Apache Ranger提供集中式的許可權管理框架，可以對Hadoop生態中的HDFS、Hive、YARN、Kafka、Storm和Solr等元件進行細粒度的許可權訪問控制，並且提供了Web UI方便管理員進行操作。

Ranger主要由三個元件組成：

Ranger Admin

使用者可以建立、更新安全訪問策略，這些策略被儲存在資料庫中。各個元件的Plugin定期對這些策略進行輪詢。

Ranger Plugins

Plugin嵌入在各個叢集元件的程序裡，是一個輕量級的Java程式。例如，Ranger對Hive的元件，就被嵌入在Hiveserver2裡。這些Plugin從Ranger Admin服務端拉取策略，並把它們儲存在本地檔案中。當接收到來自元件的使用者請求時，對應元件的plugin會攔截該請求，並根據安全策略對其進行評估。

Ranger UserSync

Ranger提供了一個使用者同步工具，可以從Unix或者LDAP中拉取使用者和使用者組的資訊。這些使用者和使用者組的資訊被儲存在Ranger Admin的資料庫中，可以在定義策略時使用。

ranger許可權模型

訪問許可權無非是定義了”使用者-資源-許可權“這三者間的關係，Ranger基於策略來抽象這種關係，進而延伸出自己的許可權模型。”使用者-資源-許可權”的含義詳解：

使用者

由User或Group來表達，User代表訪問資源的使用者，Group代表使用者所屬的使用者組。

資源

不同的元件對應的業務資源是不一樣的，比如

HDFS的FilePath
HBase的Table，Column-family，Column
Hive的Database，Table，Column
Yarn的對應的是Queue
許可權
由(AllowACL, DenyACL)來表達，類似白名單和黑名單機制，AllowACL用來描述允許訪問的情況，DenyACL用來描述拒絕訪問的情況,不同的元件對應的許可權也是不一樣的。