打贏數據安全攻堅戰，從Hadoop-security治理說起！

作者介紹

汪涉洋，來自美國視頻網站hulu的工程師，畢業於北京理工大學計算機專業，目前從事大數據基礎架構方面的工作，個人知乎專欄「大數據SRE的總結」：http://dwz.cn/7ygSgc。

前言

對於數據安全，不同的立場有不同的考量，本文主要關注公司立場的Hadoop數據安全。

對企業而言，做好Hadoop這個企業級最大的數據倉庫的數據安全是重中之重，面臨許多挑戰，但遺憾的是目前大部分公司做的還不夠完善，有的甚至形同虛設。

我最近正在實踐Hadoop Security領域，希望能整理出一個體系，並且講明白安全在大數據Hadoop體系中都有什麼知識、有哪些可做的事情。對於不同「國情」的企業，為什麼Hadoop安全方案難以實施；對於不同階段的企業，應該把Hadoop的安全實施到什麼程度。

Agenda

1.沒有Hadoop-security會出什麼問題？

2.為了有Hadoop-security，企業可以採取哪些手段？

3.Kerberos in Hadoop&分散式程序認證設計

4.企業方案選擇

沒有Hadoop-security會出什麼問題？

關於這個話題，筆者覺得還是用案例來說明比較適合，因為太技術的表達不僅干，還沒意思。

1.用戶不經過認證，可以偽裝成」任意其它用戶「做任何事情，包括「惡意事件」。

可以 delete / update 任意的HDFS文件 和 Hive tables。

可以提交任意的Hadoop job到任意Queue，導致集群資源緊張時，管理員無從管治。

事實上很多公司的Hadoop集群都沒有配置安全認證，都是裸跑，安全隱患非常大。而僅僅的一個好消息是——Hadoop集群往往都是供公司內部的數據分析師使用，因此大多部署在公司內網，外網的人很難直接訪問。

但也有一些關於Hadoop被攻擊的新聞，給大家參考：

How to secure 『Internet exposed』 Apache Hadoop - Cloudera Engineering Blog

http://blog.cloudera.com/blog/2017/01/how-to-secure-internet-exposed-apache- hadoop/

Hadoop集群遭遇勒索軟體攻擊

http://toutiao.secjia.com/hadoop-cluster-under-ransomware-attack

全球大數據系統遭勒索，觀數科技出手對抗Hadoop風險-CSDN.NET

https://www.csdn.net/article/a/2017-02-07/15817281

這是由於Hadoop集群有一些網路拓撲中的「邊緣機器」，可以被外網訪問，於是外網黑客找到了突破口，成功攻進了內網Hadoop集群。

那如何偽裝成「超級用戶」呢？筆者覺得這已經不是秘密了，就直接把鏈接放出來，畢竟做好安全才是正道：

客戶端用戶法：Impersonate as superuser on client shell. Author.. and Authen.. In Hadoop - Cloudera Blog

http://blog.cloudera.com/blog/2012/03/authorization-and-authentication-in-hadoop/

環境變數法：How to specify username when putting files on HDFS from a remote machine

https://stackoverflow.com/questions/11371134/how-to-specify-username-when-putting-files-on-hdfs-from-a-remote-machine

可能禁止環境變數法么？How to prevent users from modifying HADOOP_USER_NAME ?

https://community.hortonworks.com/questions/110020/how-to-prevent-users-from-modifying-hadoop-user-na.html

2.因此，Hadoop管理員會管不好Hadoop，嚴重時甚至會失控。

Admin不知道是否可以刪除一個冷數據 ( UserA 偽裝成「superuser」創建的文件 )

Admin不知道計算資源的使用情況，不知道誰濫用了資源。 ( userA 偽裝成「teamXuser」把作業提交到別的隊列 )

Admin 甚至不知道誰把重要的HDFS文件和Hive表刪掉了！

3.一個普通的Hadoop User都能查詢公司金融交易數據表，在財務知道前就了解公司這個月的流水、成交量，再把這些信息販賣給競爭對手、把數據賣給金融機構...

看了這些是不是覺得可怕？但在真實世界裡，作惡的手段只會比以上更高明。所以整體而言，公司的Hadoop管理員更應該防範的對象是內部的程序員/分析師！

企業可以採取哪些手段

目前在業界，Hadoop Security似乎還沒一個「既方便實施，又操作簡單、容易維護」的解決方案。

比如認證，Apache的官方社區Hadoop版本為了一站式地完美解決認證問題，使用了Kerberos。Kerberos是非常重的一種安全方案，一般人難以發揮好，但也是業界工程上在認證這一塊最安全的方案。

所以一句話概括Hadoop Security的實施現狀：安全和效率／易維護性是成反比的。

我們先來看看 Cloudera 和 Hortonworks 對Hadoop Security的定義

Cloudera：

Cloudera把Hadoop的安全級別定義為4級：

Level 0：即沒有任何安全，裸跑。大多數公司的集群都是從這裡開始的，因為沒有安全的集群搭建速度很快，容易上手，但也毫無安全可言。User可以偽裝成任何其它User，甚至「超級用戶」，去給Namenode／Datanode發送RPC請求，甚至可以直接向Datanode請求讀取block。

Level 1：從這開始就有了基本的安全。首先，建立起認證機制，讓每個用戶在訪問Hadoop集群時一定證明了「自己是自己」。然後再建立授權機制，給相應的User／Group予以不同的訪問許可權。當然最好還有審計工作，記錄下來誰在什麼時間，對集群做了什麼操作，這些操作都會被嚴格紀錄下來。

可是，Cloudera認為這還不夠安全，因為這些措施可以「防住」普通的用戶，但並不能防住「Hadoop-admin」自己，Hadoop-admin還可以像我上面說的，訪問公司的敏感數據。走到這一步，對人的管理會稱為瓶頸。

Level 2：要有更強的安全。整個集群的所有數據，或者至少是公司級的敏感數據，需要加密！ 應該有統一的密鑰管理中心管理著每一類數據的訪問密鑰。還有數據治理，也變得更加關鍵。數據治理要做到，哪些人訪問過「Hive元數據」，這些行為應該被更嚴格的審計！

Level 3：最高級別的安全。全數據中心的所有數據都是加密的，而且密鑰管理中心做到了高可用HA。使用／訪問集群的任何行為，都會被審計，並且達到了行業的審計標準。審計還不光光包括Hadoop相關的組件，任何使用Hadoop的程序、與Hadoop相關的程序，都應該被嚴格的審計。

cloudera-hadoop security levels

Hortonworks：

Hortonworks把Hadoop的安全定義為5個方面，但他並沒有給出具體的安全級別：

1.管理中心。 用來統一設置集群的安全策略。

2.認證。 證明你是你。

3.授權。 你能幹什麼。

4.審計。 你幹了什麼。

5.數據保護，數據加密。 怎麼加密，怎麼管理加密。

hortonworks hadoop security

縱觀Cloudera & Hortonworks社區的Security文章，Hadoop Security的知識範疇，分為下面5個領域。它們之間既有相互的依賴，又有其解決相應問題的獨到之處：

1.Authentication & Authorization (演算法隔離，秘鑰，加密演算法)

2.Hadoop-client Management (物理隔離)

3.Audit（審計）

4.數據加密 （密鑰管理中心及其高可用）

5.自動化管理後台

後文我會提到這幾方面，講述為什麼不同的公司實施這些安全方面的工作如此之難。

Kerberos in Hadoop&分散式程序認證設計

Hadoop安全里最重要的一個組件是Kerberos，如果沒有認證，絕對安全就無從談起。

Kerberos協議為什麼更安全？

我們在使用IT系統，涉及系統內的私密個人信息時，都需要認證。認證是一個簡單的信息交換過程， 即用戶向服務證明你是你。

典型的認證過程中，有三個參與方面 ： 客戶端、傳輸信道、伺服器。而所謂的「不安全」，在這三個參與方處都有可能發生。

1.認證問題很嚴重

在Web時代，網路總是很不安全，發生過很多問題。Owasp組織每年都會總結出每年互聯網世界中Top10的安全問題，並給予建議。而身份認證，常常排名在前3名。

Owasp Top 10

2.認證不安全的場景

客戶端C：

C1.憑證填充，使用已知密碼。你的瀏覽器是否開啟了記住密碼自動填充？他人是否可以在你不在時使用你的賬號登陸某些網站？

C2.應用會話超時設置不正確。用戶使用公共計算機訪問應用程序後，用戶直接關閉瀏覽器選項卡就離開，而不是選擇「註銷」。攻擊者一小時後使用同一個瀏覽器瀏覽網頁，而當前用戶狀態仍然是經過身份驗證的。

伺服器S：

S1. 伺服器存儲用戶密碼的資料庫，使用明文存儲。網站端工作人員可以盜破用戶密碼。

S2. 伺服器要求的密碼位數太短，太簡單，導致用戶密碼，在分散式算力強大的時代背景下，容易被「暴力破解」。比如，著名的「彩虹表」。

S3. 伺服器端網路不安全，被攻破，被拖庫。

信道Channel：

CH1. 黑客監聽／截獲網路數據包。黑客已經攻入網路，可以監聽到用戶到server端的發送報文。黑客如果截獲的信息是明文，就是最壞的情況。黑客如果截獲的是密文，仍可以採取「破解密碼」 or 「篡改並重發報文」等作惡手段，達到目的。

3.Kerberos特徵及解決認證的問題

kerberos 認證流程圖

Kerberos解決了以上所有問題：

1.登陸會話及過期，保證登陸狀態有時效性。時效性短，但客戶端可以refresh。極大的改善了C1、C2。

2.Kerberos存儲密碼的KDC資料庫及其技術可信，被證明過是「可信的第三方」。

3.密碼不用在信道傳輸，從根本上去除CH1中的密碼被截獲的可能性。

4.信道傳輸的東西是加密的，且信道傳輸的信息也是有時效性的。

信息還是有被暴力破解的可能性。但只要使time(session-key 過期)

這一章節的目的不是去講Kerberos細節，而是講Kerberos與Hadoop的結合，以及Hadoop當中涉及Kerberos的設計思路，給我們設計「安全的分散式程序「的啟發。

Hadoop在使用Kerberos上的特點及經驗是什麼？

在分散式的場景下，絕對安全很複雜。分散式意味著「結點」以及「進程」的分散。

在企業級這個level，公司集群動輒幾百上千的機器，公司內又有無數的程序員在用開發機器作為客戶端在訪問這些集群，那麼結點進程互相之間的認證就是一個更加複雜的網。

Hadoop可以算是分散式安全領域的top開源項目，那麼其在分散式背景下的安全框架設計，肯定有值得我們琢磨的地方。

1.Kerberos Principals

Kerberos中最重要的概念是Principal，可以把它理解為用戶或服務的名字，是全集群唯一由三部分組成的：username(or servicename)/instance@realm。

Username or Servicename：在本文里為服務，HDFS的2個服務分別取名為nn和dn，即NameNode和Datanode。

Instance：在本文里為具體的FQDN機器名，用來保證全局唯一（比如多個Datanode節點，各節點需要各自獨立認證）。

Realm：域，我這裡為http://TEST.COM（全大寫喲）。

Hadoop 會為每一個host每一個process都生成Principal。比如為HDFS的 NameNode和 Yarn的ResourceManager都生成各自的principal。這讓整個Hadoop的Security達到了一個高水準，細節請看:Hadoop in Secure Mode（https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/SecureMode.html#Introduction）。

namenode resourcemanager 按 name/host@realm 的格式創建的principal

2.分散式中的認證場景

在一個絕對安全的分散式場景下，每兩台Server之間互相聯繫，都需要認證彼此。如果一個Cluster有N台機器，理論上是要有 N平方對的請求需要獲取Kerberos Ticket。

我們按系統的部署複雜度，漸近式地羅列認證場景：

最簡模型

要求認證者只有一台伺服器，這是最簡模型，沒什麼好說的。標準的Kerberos模版。

簡單的分散式部署場景

參與者是一個「鏈」，甚至是一顆「樹」。比如一個大型應用系統 、web伺服器與資料庫／緩存伺服器的分離，以及大型公司內部微服務化的部署。

複雜的分散式部署場景

在Hadoop系技術棧下，基本都是複雜的分散式部署場景，組件的「種類」多，組件的「數量」也多。兩兩之間在通信（發送RPC請求）時，都需要彼此「認證」。

airflow/azkaban 向 Hadoop 提交

複雜的分散式場景

3.Hadoop認證場景的特點Scenario

S1.某些門戶伺服器，負責接受用戶請求，然後代用戶，向後方真正的集群進行交互。

比如在用戶使用諸如Hive/ Oozie / Azkaban 提交job時，用戶希望真正提交到 Yarn 里的 job 的User還是用戶自己。

比如在Ceph中，Client端可以通過 http-api／s3-api / swift-api 等方式訪問 Ceph os Gateway。而Gateway server這個跳板，又會模擬用戶去真正的調用librados。

Ceph Gateway - 1

Ceph Gateway - 2

S2.用戶提交的計算任務，分散式運行。運行的子task都以提交用戶的許可權去訪問其它「第三方」系統。

比如：Hadoop用戶提交的Mapreduce job，在每一個task中都有可能訪問HDFS。在訪問HDFS時，以提交job的用戶來訪問HDFS，甚至其它第三方Service。

4.這些場景會產生以下幾個問題 (Question)

在場景S1下，Gateway伺服器是連接用戶和系統的屏障，Gateway伺服器還要能裝扮成「原提交用戶「去和後端系統交互。

Q1-S1. principal & keytab 泛濫，管理困難。

根據上面Kerberos Principal的定義 Username/instance@realm，同一個用戶在不同的機器上，是需要配置不同的Principal的。倘若公司內有m個用戶，n台Gateway機器，就要預先定義m＊n個Principal，且新創建的Gateway機器都要重複這個過程。而且這些Gateway伺服器在做kinit操作時，又要使用keytab，這都會導致對Principal以及其對應的keytab (what is a keytab)的管理變的困難。

在場景S2下，計算job會生成很多的子計算任務，且分散在集群的很多機器上。這不僅僅會引起Q1-S1同樣的問題，還會更嚴重。一個大型公司的Hadoop Cluster，上面每天甚至會跑幾萬幾十萬的job。每個job又會生成很多的Mapreduce 子task，這些job的生命周期從幾分鐘到天不等。

Q2-S2. 加強版Q1-S1.

由於job的短生命周期，而產生的大量短生命周期Principal & Keytab

Q3-S2. KDC承受壓力，有dos的風險(deny of service)。

在一些大的job launch時，會有很多很多的子task瘋狂的訪問KDC,而Kerberos涉及了很多的加解密操作，KDC本就是CPU密集型應用，再加上Handle大量的網路請求，很有可能導致 deny of service，讓其它訪問KDC的正常Kerberos請求不可用。

Q4-S2. long-running的job，ticket會過期，需要處理好。

很多Hadoop上跑的Mapreduce job，都會跑很久，甚至好幾天。而Kerberos的Session key在設計之初，就是要過期，防止暴力破解的。那這些job需要去Renew他們的ticket。怎麼實現？

5.Hadoop這些問題的解決之道，以及對設計「分散式系統安全」的可借鑒經驗(solution)

Q1-S1. principal & keytab 泛濫，管理困難。

常規解法：kerberos forward/proxy ticket ， 讓gateway機器可以使用客戶端的ticket，訪問後端機器。

Oracle : kerberos forwardable ticket doc

https://docs.oracle.com/cd/E19253-01/816-4557/user-68/index.html

Delegation of Authentication (proxy & forwarded tickets)

https://technet.microsoft.com/en-us/library/cc961964.aspx

Forwardable ticket

缺點：不論是Proxy還是Forwardable ticket，都需要在客戶端kinit時，把Gateway機器／後端機器加入kinit的參數當中。其次這種ticket的時效性管理貫穿多台機器很麻煩。總之，這種實現的複雜度比較高，和Kerberos協議耦合太深。

Hadoop解法：impersonate | proxy user。

Proxy user - Superusers Acting On Behalf Of Other Users

https://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-common/Superusers.html

Hadoop提供了一種使用超級用戶，偽裝成普通用戶訪問集群組件的辦法，這種辦法在Hadoop的代碼級別做了支持。在Gateway機器和後端機器進行RPC Kerberos認證時，仍然使用Gateway機器上的Principal去獲取tgt。

但真正在做訪問控制時，使用Impersonate技術，Superuser會模擬普通用戶。這就解決了Q1-S1問題。這是以犧牲一部分絕對安全性為代價，換來了複雜度的減少。不過由於在企業內部，Gateway機器及後端機器都是被管理員嚴格控制的，所以這是一個行之有效的技術。

Tips：還有一個比較生動的例子來解釋這個Solution的合理性：

一個「警察」，他擁有超越普通公民的權利，但他在執行任務時，可以裝扮成便衣，這樣他在訪問商店，辦理事務時，會被作為「普通」公民對待。這是合法的。但一個普通公民，你要是裝扮成「警察」，那就應該被抓住，是違法行為。

Impersonate技術並非允許所有Gateway伺服器／所有進程，都可以做Impersonate。這種行為是被嚴格控制的，需要Admin把這些配置在Hadoop的配置文件中。

Q2-S2. 解決辦法同上Q1-S1。

Q3-S2. KDC承受壓力，有DOS的風險(deny of service)。

常規解法：給KDC做Sharding，做負載均衡。

是的，KDC不外乎也就是一個Server，下面掛一個DB，那麼理論上肯定是可以做Sharding和負載均衡的。但這樣做會又本來就複雜的實施Kerberos環境增加了更多的複雜性。

Hadoop解法：Delegation-Tokens

這個Delegation-Tokens值得好好的說一說。上面我們提到了大量的Mapreduce tasks 會造成KDC的 DOS (deny of service)。我們通過下圖看一下：

map-reduce tasks on workernodes

圖中的紅線表明: 一個MR job里，會切分成很多的Workernode的task進程，他們在運行時，會向HDFS的NameNode，或者Hadoop的其它組件諸如KMS，發出RPC請求。

我們知道，在Kerberos環境中，每一次RPC請求都要經過驗證，都要去KDC獲取TGT，那麼這就會導致KDC承受大量的traffic。

所以Hadoop就弄出了Delegation Tokens這樣一個輕量級的Authentication解決方案來代替分散式MR job場景下的Kerberos authentication。Kerberos是一個三方協議，相反, Delegation Token認證是一個兩方協議。

Delegation Tokens的工作原理：

Client通過Kerberos和NameNode初始化認證，然後請求NameNode拿到一個Delegation Token。

Client把Delegation Token放入提交的job的context，發送給Yarn Resourcemanager。

Yarn RM 把job的執行環境初始化好，然後啟動很多Container去跑MR job的子tasks，把Delegation Token 通過Container的Context再一次下發給Workernodes。

每個Workernode上的子task進程都使用這個Delegation Token去訪問NameNode，而並不用再去請求一次KDC來獲取TGT。

當job結束後，RM負責去NameNode把這個Delegation Token銷毀。

整個流程如下圖：

Delegation Token 生命周期

Delegation Token解決了分散式計算任務這種場景下，短生命周期的「子計算進程」導致的Principal泛濫，重複性的給KDC造成大量請求Traffic的問題。 但這種解決方案的代價也是以犧牲了一定的安全性換來的，好在Hadoop Admin對整個集群是可控的。

Q4-S2. long-running的job，ticket會過期，需要處理好。

這個問題是真對Hadoop上的計算任務的，普通的計算任務，time(job生命周期)

這個問題對我們設計分散式系統，並沒有什麼借鑒之處。在這裡提出來，主要是因為ticket的renew，設計很複雜。那麼跑在Hadoop上的計算框架，必須要自主去實現這些ticekt Renew的邏輯。

通常很多on-Yarn的非官方Application，在Coding時並沒有考慮這些，因此，這會對「部署Keberos」造成很大的挑戰。這也是後面我們提到的對Apply Kerberos安全功能到線上的難點之一。

6.小結——Hadoop給我們設計分散式系統提供了哪些經驗：

1.在分散式環境下，我們可以做一些tricky的設計，捨棄「三方認證」帶來的絕對安全，退化成局部「兩方認證」來達到相對的安全。因為用Kerberos來保證絕對安全，實現複雜度太高，在實現時甚至可能引入更多的bug。

2.Impersonate是在鏈式安全認證模式下，解決Gateway伺服器模擬最初用戶，訪問後端伺服器。

3.Delegation Token是一個在分散式環境下，針對大量的計算型短生命周期進程，產生的短生命周期Kerberos Principal泛濫，造成KDC Server DOS問題的解決方案。

Hadoop實施Kerberos功能為什麼這麼難？

Kerberos上線，為什麼難？因為整個Hadoop系統需要「重新配置」、「重新分發配置」，客戶程序代碼也可能需要改變，才能重新跑起來。

這不但需要停機，還可能因為Update，導致啟動後進入不穩定的狀態。從而會導致對公司線上業務造成很大的影響。

我從Admin & Client兩個維度去羅列，把Kerberos上線大致需要做哪些事情，然後自然就能體會為什麼難以實施。

Admin side：

每一個Hadoop組件都必須全部停機，重新配置。

所有服務的CONF文件都需要重配，加入Kerberos的安全參數，然後重新分發，再重啟這些Hadoop組件。

具體的配置步驟，可以參考Cloudera社區，或者Hortonworks社區，我這裡截一個圖，來證明需要重配的組件有多少。

1.Cloudera : Configuring Authentication

https://www.cloudera.com/documentation/enterprise/5-8-x/topics/sg_authentication.html

2.Setting Up Kerberos Authentication for Non-Ambari Clusters

https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.3/bk_security/content/setting_up_kerberos_authentication_for_non_ambari_clusters.html

cdh/hdp Kerberos auth conf

需要有一個KDC，且必須高可用，且必須與公司內部現有的員工賬戶體系打通。

HA 是必須的, 否則 KDC會成為 Hadoop 系統的新 SPOF。

KDC 必須和公司員工賬戶體系打通。公司的個人開發機，以及所有staging／prod機器，其上的linux user/group，在KDC 的資料庫里必須存在，否則從這些機器發出的Kinit認證將會不通過。

由於歷史遺留問題，很多非個人的賬戶的文件已經存在於HDFS中，他們的ACL設置可能不正確。那麼這些賬戶的文件在被讀取時可能會有問題，需要摸清楚哪些非個人賬戶需要「預先」在KDC創建，他們的文件ACL設置是否合理。

Keytab文件的分發／管理，也需要有強大的管理工具來支撐。

User side：

所有的Hadoop Client機器Conf都必須重配置，重啟。

這會牽扯到「所有的「Data團隊、所有Hadoop Client，所有的Application client，這將是一個實施的最難點。

調度系統需要重新配置

Airflow／Azkaban／oozie ／以及自研的調度系統，其worker也是Hadoop Client，也需要重配。

On-Yarn的應用，需要重構

我們在前文提到了long running的job是一個問題。正常的生命周期超過Kerberos ticket expiretime的job，也是一個問題。而恰好 MR 和Spark這兩個計算層的框架，幫我們解決了這些問題，諸如ticket renew等等。

那麼自研發的on-Yarn應用，就要自己來重構Kerberos相關的代碼了。

感興趣的朋友可以讀一讀Hadoop Apache社區的文檔：YARN Application Security

某些公司的MR／Spark程序，也可能跑不起來。因為在沒有Kerberos時，可能沒有注意ACL的問題，使用諸如 「export HADOOP_USER_NAME=hdfs」這種大鎚，那麼在Kerberos上線後，這些程序都會出問題，需要重構。

小結：不論管理員／用戶，引入Kerberos的代價都及其的高，必然會影響線上業務，必然會使公司的大數據業務shutdown一段時間，且還存在核心pipeline啟動不起來的風險，你說這種項目的實施難度得多大？ 所以上線難。

退而求其次的解決方案

如果Kerberos這麼難以實施，那怎麼辦？有沒有不絕對安全，但相對能簡單可實施的解決方案呢？

答案是：堡壘機 ＋ 審計。

堡壘機上部署Hadoop Client，按「組」控制好粒度。

嚴格配置每個組的用戶，不同組的用戶不可以登陸到不屬於自己Team的堡壘機。嚴格控制HDFS/Yarn 這種超級用戶在堡壘機創建。不讓用戶"sudo su superuser"。

每個組只部署他需要的Hadoop組件Client Conf，不需要的不給予部署。比如用不到直連ZooKeeper的，就不給他ZK Conf。只連Hive的，就只給他配Hive Conf。

堡壘機審計。

堡壘機是沒有辦法禁止用戶做操作 「export HADOOP_USER_NAME=hdfs"的。但我們可以管理好用戶的每一次登陸，管理好用戶的歷史commands，做到「事後能追查」。

這樣能做到把Hadoop用戶的活動範圍限制在最小的範疇內。

在發生壞事時，可以根據Hadoop的審計日誌，查詢到是哪個IP幹了壞事，然後通過IP找到對應的堡壘機，就可以落實到Tteam。再根據堡壘機的審計日誌，可以定位到是哪一次Session，即：誰，在什麼時間，操作了什麼指令。

Tips：審計就好比：法律是不允許殺人的，但是並不能預先阻止你殺人。而是在你殺人後審判你。因為絕對要防止你殺人，社會成本太高。

除了堡壘機，還有別的土辦法嘛？

有，比如Hack NameNode 的代碼， /a/b/c 這種三層以內的路徑刪除操作，來自其它機器的全部過濾掉，只有來自Admin結點的，予以執行。

Hive 的drop table 、Hbase 的刪除表也都同理。這種辦法看上去很low，但實際上也work的不錯。

總結

安全是追求犯罪率的最低化，同時是控制預防犯罪的成本。絕對安全在現實世界並不一定最有意義。Kerberos的過期sessionkey設計，也是追求密鑰更新的時間間隔小於被破解時長。

Hadoop使用了Kerberos，但在一些特殊的場景時，Kerberos會遇到性能瓶頸和實施複雜度瓶頸。Hadoop使用「把三方認證退化為局部兩方認證」 的Impersonate 和Delegation Token技術順利地解決了問題。

Kerberos on Hadoop 很難實施。如果實在阻力大，還有一些相對容易的方案可選。

附錄：Ceph是一種分散式的對象存儲解決方案。它的認證就沒有使用Kerberos，而是使用了一種叫Cephx的變種Kerberos協議。Cephx ,authentication protocol #high-availability-authentication。

它把KDC的概念揉進了Ceph自己的組件monitor，避免了SPOF，且Cephx發出的session-key，在所有不同角色的Ceph Component Server之間是通用的。這個設計和Hadoop的Delegation Token有異曲同工之妙。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！