權限的管控，歷來是大數據平臺中最讓人頭疼的問題之一。管得嚴了，業務不流暢，用戶不開心，放得寬了，安全沒有底，你能放心？而且大數據平臺組件，服務衆多；架構，流程複雜，有時候，就是你想管，也未必能管得起來。
涉及到具體的技術方案層面，Kerberos，LDAP，Sentry，Ranger，Quota，ACL，包括各個組件自己的權限管控方案，這些話題，不是一小節的篇幅能夠覆蓋的，所以，不打算在這裏詳細討論各種技術方案。
所以，還是讓我們來談一下權限管控的目標。從我司當前階段來看，我們的權限管控目標，是防君子不防小人。此話怎講？權限管控，大家都知道，有兩個步驟：認證（authentication）和授權（authorization）。前者鑑定身份，後者根據身份賦予權限。
我司當前的權限建設重點目標在於授權這個環節。如何對權限點進行集中統一的管理；如何讓用戶自主的申請權限；如何把權限的管理工作交給具體的業務負責人而不是平臺管理員；如何在不同的組件之間，不同的用戶之間打通權限關係。這些工作，在當前複雜的生態環境中已經夠我們忙一陣子了。
至於用戶身份的鑑定這個環節，比如Kerberos這種方案，我們就暫時沒有采用。原因很簡單：覆蓋面不全，應用代價太高，收益不明顯。對於用戶身份的鑑定，我們的主要目標是防止無意的誤操作，而非蓄意的身份僞造。有很多種代價更低的用戶認證方式能達到這個目標。
所以，權限的管控，做多少，怎麼做，花多少代價，取決於你的目標出發點，我司集成開發環境的權限管控目標：是對用戶常規的業務行爲範圍進行限定，敏感數據的控制固然是一方面，但更重要的是對業務邏輯和流程的約束，通過減少用戶不必要的權限，減小受害面，降低可能的業務風險，同時也便於明確用戶的權責歸屬關係。
常見開源方案
權限管理相關工作可以分爲兩部分內容：
一、管理用戶身份，也就是用戶身份認證（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，當前的實現如果剛好適合你的需求自然最好，如果不適合，那還需要自己再想辦法，且看他們將來的發展吧。
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標準授權模型
基於開發平臺服務入口的權限管控思路 瞭解了相關的解決方案和思路，在我們自己的大數據平臺的權限管理方案的實施過程中，不管是全面使用開源方案，還是局部混搭，又或者是完全自行構建，我們都可以從身份認證與授權管理，集中式管控與Gateway邊界管理等角度來拆解，思考和分析問題，尋找適合自身業務場景的整合方案。
我司的整體思路，是儘可能通過構建產品化的大數據開發平臺，將各種集羣以服務的形式對外提供，換句話說，類似於上述Gateway的思想（但不是knox這種http代理），儘可能讓用戶通過開發平臺來提交任務，管理數據，而不是直接通過API連接集羣。
當所有的用戶都通過開發平臺來和集羣進行交互時，開發平臺就具備了統一的用戶身份認證和權限管理的基礎前提條件。當然實際情況並沒有那麼理想，不管是出於技術原因，實現代價原因，程序效率性能原因，還是業務流程原因，總會有些業務流程和任務無法通過開發平臺來統一管控。這時候就需要結合其它方案來彌補了。
以HDFS集羣的文件讀寫的權限認證爲例，大部分涉及到HDFS文件讀寫的任務，比如Hive/Presto/SparkSQL等相關任務，如果我們管控了這些任務作業的提交入口，相關的集羣由我們提供，那麼多數權限管控工作我們都是能夠在開發平臺層面完成管控的。
但還有很大一部分需要讀寫HDFS數據的業務，自身並不運行在大數據開發平臺提供的服務上。比如內網的簡歷系統需要存取簡歷，商家的證照文件需要備份，廣告的算法模型，特徵數據需要在各個子系統間傳輸等等，這些業務的程序可能是自行開發的，調用入口也並不在大數據開發平臺上，所以開發平臺也就很難對其進行用戶身份認證。
而Hadoop的客戶端，除了Kerberos方案，剩下的Simple認證方案，實際上並不真正識別用戶的身份（比如你只需要通過環境變量設置宣稱自己是用戶A，Hadoop就允許你操作用戶A的數據）。那麼不上Kerberos就沒法處理了麼？
也不完全如此，如果用戶的需求是簡單的文件存儲工作，那麼我們可以考慮通過對象存儲服務的方式來支持，用戶身份的認證在對象存儲服務中實現，由對象存儲服務代理用戶在HDFS集羣上進行文件讀寫操作。但如果用戶就是需要靈活的Posix模式的文件讀寫服務，那顯然，就要在HDFS自身服務方面動腦筋了。是封裝客戶端還是改造服務端，取決於具體的安全需求程度和實現代價
基於服務端的改造通常對用戶的透明性好一些，安全性也更強一些（因爲別人可以不用你封裝好的客戶端。當然，也可以在服務端加上客戶端的ID識別之類的工作來加強防範）。比如，如果我們相信業務方自己不會濫用賬號，我們的目的只是防止各個業務方之間無意的互相干擾和誤操作，那麼在服務端進行用戶身份和IP來源的綁定鑑定（即特定用戶只能由特定IP的機器使用），結合Hadoop自身的Posix文件權限管理模式，基本就能達到目的。當然，服務端的管控還可以想到更多的其它方案，這就需要結合你的業務環境，運維成本和技術代價等進行判斷選擇了。
再比較一下底層統一權限管控平臺和基於開發平臺進行邊界權限管控的優缺點 首先，Ranger等方案，主要依託大數據組件自身的方案，Hook進執行流程中，所以管控得比較徹底，而開發平臺邊界權限管控，前提是需要收攏使用入口，所以論絕對安全性，如果入口收不住，那麼不如前者來得徹底。不過通常來說，爲用戶提供統一的服務入口，不光是安全的需要，也是開發平臺提高自身服務化程度和易用性的必要條件。
其次，底層權限統一管控平臺，因爲依託的是大數據組件自身的方案，並不收攏用戶交互入口，所以身份認證環節還是需要依託類似Kerberos這樣的系統來完成。而開發平臺服務方式，收攏了入口，就可以用比較簡單方式自行完成身份認證，如前所述，相比涉及到三方交互的分佈式身份認證機制，通常實現代價會更低一些。
再次，大數據組件自身的權限方案，權限驗證環節通常發生在任務實際執行的過程中，所以流程上基本都是在沒有權限的時候拋出一個異常或返回錯誤，因此不太可能根據業務場景做更加靈活的處理。
而開發平臺服務方式，權限的驗證如果可以做到在執行前階段（比如通過語法分析獲得）進行，那麼流程上就可以靈活很多，可以結合業務相關信息提供更豐富的調控手段。
例如，業務開發過程中，在代碼編輯或保存時就可以進行相關權限驗證和提示，避免在半夜任務實際執行時才發現問題。也可以定期批量審計腳本任務，或者根據業務重要程度對缺乏權限的情況進行區別對待：提示，警告，阻斷等等。簡單的說，就是你想怎麼做就怎麼做。而Ranger等基於底層組件進行Hook的權限架構方案，一來沒有相關業務信息無法做出類似決策，二來考慮通用性，很多平臺環境相關業務邏輯不可能也不適合綁定進來。
當然，這兩種方案並不是互斥的，如何定義你的產品，如何拆分各種需求，對你選擇權限管控方案也有很大的影響。更常見的情況是，你會需要一個混合體，取長補短，彌補各自的不足之處。
小結 總體來說，在開發平臺上進行邊界權限管控，並不是因爲這種方式更安全，而是因爲它更靈活，與業務和流程的兼容適配性更好，對底層組件自身權限管控能力的依賴性也更小。甚至還可以根據業務邏輯針對性定製權限管控策略，但是因爲自身通常並不深度Hook具體組件內部執行邏輯，所以部分場景可能無法有效的進行管控（比如二進制代碼任務無法從外部解析其讀寫邏輯），就需要和底層組件權限管控方案結合起來實施。
換個角度來說，這也是在開發平臺的產品化過程中，很多任務我們會希望儘可能SQL化／腳本化／配置化的推動動力之一。一方面SQL化／腳本化／配置化有助於降低用戶的開發成本，可以做一些系統層面的自動優化，沉澱知識和最佳實踐。另一方面，有了可供解析語義的文本，也便於根據語義進行權限管理，儘可能完善平臺邊界權限管控的能力和範圍。
作者：Albert陳凱 著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。