去年我把一套跑了三年的 Hadoop 離線平臺(tái)逐步遷到 Spark 上做實(shí)時(shí)計(jì)算時(shí)原本以為 Hive 和 HDFS 上已經(jīng)配好的 Ranger 權(quán)限策略能直接繼承過(guò)去結(jié)果上線當(dāng)天就有業(yè)務(wù)同學(xué)通過(guò) Spark SQL 讀到了權(quán)限表之外的明文手機(jī)號(hào)。那一刻我才真正意識(shí)到在大數(shù)據(jù)平臺(tái)里隱私保護(hù)配置從來(lái)不是“配一次就一勞永逸”的事從 Hadoop 遷移到 Spark幾乎等于把整套保護(hù)體系重新梳理一遍。這篇內(nèi)容就是記錄我在實(shí)際切換過(guò)程中的完整思路和配置清單包括哪些 Hadoop 時(shí)代的組件必須保留、Spark 側(cè)需要補(bǔ)充哪些隱私保護(hù)配置、策略遷移時(shí)如何驗(yàn)證一致性以及我踩過(guò)的幾個(gè)真實(shí)坑。適合正在做 Spark 替換 Hadoop 作業(yè)、或者新集群需要同時(shí)兼容兩套引擎的同學(xué)參考。1. 隱私保護(hù)從 Hadoop 換到 Spark 后為什么會(huì)出現(xiàn)“斷檔”很多人會(huì)想當(dāng)然地認(rèn)為Hadoop 平臺(tái)上的 Kerberos 認(rèn)證、HDFS 權(quán)限、Ranger 授權(quán)都已經(jīng)配好了Spark 跑在同一個(gè)集群上應(yīng)該自動(dòng)繼承。結(jié)果往往不是這樣。要理解這個(gè)“斷檔”得先看清楚 Hadoop 和 Spark 在權(quán)限控制邏輯上的根本差異。1.1 權(quán)限控制的對(duì)象變了從“讀文件”變成“讀內(nèi)存里的數(shù)據(jù)”在傳統(tǒng) Hadoop 生態(tài)里數(shù)據(jù)幾乎都以 HDFS 文件形式存在。無(wú)論走 MapReduce、Hive 還是其他組件最終都會(huì)落到“打開(kāi)文件、讀取塊、返回記錄”這條路徑上。因此權(quán)限控制可以非常自然地做在 HDFS 層、Metastore 層或者 HS2 入口只要把文件的 ACL、目錄的屬主、Hive 表的授權(quán)策略布控好基本就能覆蓋絕大多數(shù)訪問(wèn)場(chǎng)景。Spark 則不然。Spark 作業(yè)啟動(dòng)后數(shù)據(jù)會(huì)被讀取進(jìn) Driver 和 Executor 的 JVM 內(nèi)存變成 RDD、DataFrame、Dataset 這些暫無(wú)實(shí)體文件的抽象結(jié)構(gòu)。權(quán)限控制如果只做在存儲(chǔ)層那么在數(shù)據(jù)入內(nèi)存之后誰(shuí)對(duì)哪些列做了投影、誰(shuí)做了聚合、誰(shuí)把結(jié)果寫(xiě)到了哪里存儲(chǔ)層幾乎感知不到。這里就出現(xiàn)了一個(gè)很微妙的入口空缺Spark 數(shù)據(jù)計(jì)算的合法性更多要依賴任務(wù)提交時(shí)的身份、任務(wù)運(yùn)行時(shí)的訪問(wèn)請(qǐng)求、以及結(jié)果輸出位置來(lái)管控而不是傳統(tǒng)意義上“誰(shuí)摸到了這個(gè)文件”。舉個(gè)我在實(shí)際遷移中遇到的例子Hive 用戶通過(guò) JDBC 查詢一張表時(shí)Ranger 的 Hive 插件會(huì)攔截 SQL判斷用戶是否有 SELECT 權(quán)限。但同一個(gè)用戶用 PySpark 的spark.table(db.sensitive_table)直讀時(shí)如果 Spark 沒(méi)有接入同一套授權(quán)插件這條路徑就可能繞過(guò) Hive 層的檢查。數(shù)據(jù)其實(shí)還是那份數(shù)據(jù)但讀取方式變了原來(lái)的攔截點(diǎn)就失效了。1.2 Ranger 策略在 Hive 上管用在 Spark 里不一定觸發(fā)Ranger 之所以在 Hadoop 時(shí)代被廣泛使用是因?yàn)樗鼘?duì) Hive 的插件機(jī)制非常成熟請(qǐng)求打到 HiveServer2插件在解析 SQL 的關(guān)鍵節(jié)點(diǎn)做權(quán)限判斷表級(jí)、列級(jí)、行級(jí)都能攔。問(wèn)題在于Spark 并不必須走 HiveServer2。常見(jiàn)的 Spark SQL 訪問(wèn)路徑有三條Spark Thrift ServerSTS方式把 Spark 當(dāng)作 HiveServer2 的替代品客戶端通過(guò) JDBC 提交 SQL。這條路徑理論上可以復(fù)用 Ranger 對(duì) Hive 的插件但需要單獨(dú)確認(rèn)插件是否支持 STS以及 SQL 解析是否經(jīng)過(guò)相同的 Hook。DataFrame 編程方式spark.read.parquet(/user/data/sensitive)完全繞過(guò) Hive 語(yǔ)義層Ranger 的 Hive 插件根本看不到這個(gè)請(qǐng)求。Catalog 方式通過(guò) V2 DataSource API 或自定義 Catalog 讀取文件權(quán)限控制取決于實(shí)現(xiàn)和 Hive 策略無(wú)關(guān)。我見(jiàn)過(guò)不少團(tuán)隊(duì)在遷移時(shí)忽略了這個(gè)差別認(rèn)為 Ranger 策略已經(jīng)覆蓋全部數(shù)據(jù)訪問(wèn)結(jié)果 Spark 作業(yè)全都在“裸奔”。所以第一條建議就是先把你的業(yè)務(wù)訪問(wèn)方式排查一遍分清哪些是走 STS、哪些是編程直讀。對(duì)編程直讀的部分別幻想 Ranger 能全兜住要在應(yīng)用層或統(tǒng)一讀取入口補(bǔ)控制。1.3 先分清靜態(tài)數(shù)據(jù)保護(hù)和流動(dòng)數(shù)據(jù)保護(hù)才不會(huì)漏配隱私保護(hù)配置最容易出的問(wèn)題是只盯著“存在磁盤(pán)上的數(shù)據(jù)”卻忽略了“在作業(yè)運(yùn)行過(guò)程中流動(dòng)的數(shù)據(jù)”。我習(xí)慣把需要保護(hù)的維度分兩類靜態(tài)數(shù)據(jù)HDFS 上的源文件、清洗后落地的表、備份快照、導(dǎo)入導(dǎo)出的中間文件。流動(dòng)數(shù)據(jù)Spark 在 shuffle 階段產(chǎn)生的中間文件、Executor 之間網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)、RDD/DataFrame 緩存到本地磁盤(pán)的部分、Spark UI 展示的執(zhí)行計(jì)劃和查詢文本。兩類數(shù)據(jù)需要的防護(hù)手段完全不同。靜態(tài)數(shù)據(jù)靠加密區(qū)、ACL、Kerberos 就夠了流動(dòng)數(shù)據(jù)則需要配置 Spark 自身的加密和認(rèn)證項(xiàng)比如 shuffle 加密、RPC 認(rèn)證、Web UI 訪問(wèn)控制。很多團(tuán)隊(duì)只做了 HDFS 加密認(rèn)為“磁盤(pán)加密 數(shù)據(jù)加密”這其實(shí)只能覆蓋靜態(tài)維度。真正的隱私保護(hù)斷檔幾乎都出現(xiàn)在流動(dòng)數(shù)據(jù)上。后面第 3 章我會(huì)把這些配置項(xiàng)逐個(gè)展開(kāi)。2. Hadoop 時(shí)代留下的三件套哪些必須保留別一提到遷移就覺(jué)得舊組件全要扔掉。Kerberos、HDFS 透明加密、Ranger/Sentry 這三件套里大部分要保留但用法和之前略有不同。我逐個(gè)說(shuō)說(shuō)我的取舍思路。2.1 Kerberos身份認(rèn)證是前提但別指望它做權(quán)限判斷Kerberos 在第一套 Hadoop 集群里往往是首先搭起來(lái)的組件。它的作用是回答“你是誰(shuí)”不回答“你能看什么”。同一個(gè) Kerberos principal可能只是某個(gè)業(yè)務(wù)賬號(hào)但如果授權(quán)策略沒(méi)配好它照樣可以訪問(wèn)所有表。很多團(tuán)隊(duì)把 Kerberos 當(dāng)成隱私保護(hù)的全部這是理解偏差。到了 Spark 階段Kerberos 的價(jià)值不僅沒(méi)有減弱反而更關(guān)鍵。Spark 作業(yè)要訪問(wèn)受保護(hù)的 HDFS必須先拿到有效票據(jù)要提交到 YARN 并運(yùn)行在集群模式也需要把 principal 和 keytab 交給 YARN 來(lái)?yè)Q取下一個(gè)階段的票據(jù)。我在遷移中最大的感受是Kerberos 配置本身沒(méi)變但 Spark 給票據(jù)管理增加了不少麻煩。首先是長(zhǎng)期運(yùn)行的 Streaming 作業(yè)。Spark Streaming 或 Structured Streaming 作業(yè)可以跑幾周甚至幾個(gè)月而 Kerberos 票據(jù)有有效期限制默認(rèn)可能只有 24 小時(shí)甚至更短。如果不在提交腳本里做好 keytab 管理和自動(dòng)刷新作業(yè)會(huì)在某個(gè)凌晨莫名其妙開(kāi)始報(bào)認(rèn)證失敗。Hadoop 時(shí)代的 MapReduce 作業(yè)短平快跑完就結(jié)束幾乎不存在這個(gè)問(wèn)題Spark 的長(zhǎng)任務(wù)直接把這個(gè)問(wèn)題暴露出來(lái)了。然后是 keytab 的權(quán)限管控。keytab 文件本質(zhì)上就是身份憑證誰(shuí)拿到它誰(shuí)就能以對(duì)應(yīng)身份提交作業(yè)。我見(jiàn)過(guò)有的團(tuán)隊(duì)把 keytab 放在 HDFS 的共享目錄下權(quán)限還是 777這就是把大門鑰匙掛在墻上。建議把 keytab 放在只有運(yùn)維賬號(hào)和指定服務(wù)賬號(hào)能讀取的位置本地路徑或受控 HDFS 路徑都行權(quán)限至少設(shè)為 400 或 600。2.2 HDFS 透明加密靜態(tài)防泄露的有效手段也有邊界HDFS 透明加密是我認(rèn)為 Hadoop 時(shí)代最值得保留的隱私保護(hù)手段之一。它在文件系統(tǒng)層面對(duì)落盤(pán)數(shù)據(jù)做加密對(duì)上層應(yīng)用完全透明。這意味著 Spark 讀寫(xiě)加密區(qū)文件時(shí)不需要改任何業(yè)務(wù)代碼KMS 會(huì)自動(dòng)完成加解密。對(duì)于包含明文手機(jī)號(hào)、身份證、地理位置等數(shù)據(jù)的 S1 級(jí)敏感數(shù)據(jù)我都建議放加密區(qū)。創(chuàng)建加密區(qū)并不復(fù)雜。先確保 KMS 服務(wù)正常然后生成一個(gè)加密密鑰再把目標(biāo)目錄設(shè)置為加密區(qū)# 通過(guò) KMS 創(chuàng)建加密密鑰256 位 hadoop key create mykey -size 256 # 創(chuàng)建加密區(qū) hdfs crypto -createZone -path /data/sensitive -keyName mykey # 驗(yàn)證加密區(qū)是否生效 hdfs crypto -listZones要注意一個(gè)邊界HDFS 透明加密只解決“靜態(tài)數(shù)據(jù)”的泄露問(wèn)題比如磁盤(pán)被拔走、備份介質(zhì)丟失、未授權(quán)用戶直接讀數(shù)據(jù)塊的場(chǎng)景。它并不能阻止一個(gè)擁有合法 Kerberos 憑證的 Spark 作業(yè)將數(shù)據(jù)讀取后落盤(pán)到普通目錄也不能阻止作業(yè)把數(shù)據(jù)計(jì)算結(jié)果顯示在日志里。所以我在遷移方案中把它的定位設(shè)為“基礎(chǔ)防線”而不是“唯一防線”。另外還有一個(gè)容易忽略的點(diǎn)KMS 本身要高可用密鑰輪換策略要提前定好。否則一旦 KMS 節(jié)點(diǎn)出問(wèn)題所有加密區(qū)數(shù)據(jù)的讀寫(xiě)都會(huì)受阻Spark 作業(yè)會(huì)大面積失敗。這不是 Spark 的配置問(wèn)題但遷移時(shí)你一定會(huì)遇到。2.3 Ranger/Sentry 策略保留表級(jí)授權(quán)慎用列級(jí)脫敏Ranger 或 Sentry 在 Hadoop 生態(tài)里負(fù)責(zé)的是數(shù)據(jù)授權(quán)。我強(qiáng)烈建議不要因?yàn)橐?Spark 就把 Ranger 撤掉表級(jí)權(quán)限這道防線依然非常有效。Hive 表層面的db.table粒度控制可以擋住絕大多數(shù)“我不該看這個(gè)表”的訪問(wèn)。但在 Spark 場(chǎng)景下我對(duì) Ranger 的態(tài)度是“部分信任”。前面已經(jīng)說(shuō)了Ranger 的 Hive 插件攔截的是 HiveServer2 的 SQL 請(qǐng)求一旦 Spark 走編程直讀路徑策略就不一定生效。因此我一般這樣分層表級(jí)控制繼續(xù)用 Ranger 管理對(duì)所有走 Hive、Spark Thrift Server 的 SQL 請(qǐng)求做兜底。列級(jí)脫敏如果業(yè)務(wù)上游需要通過(guò) Hive SQL 查看敏感表可以用 Ranger 的 Masking 功能對(duì)某些列做動(dòng)態(tài)脫敏。但這么做的前提是訪問(wèn)路徑確實(shí)經(jīng)過(guò) Ranger 插件使用前最好實(shí)測(cè)驗(yàn)證。編程讀取凡是spark.read、spark.table之類的代碼路徑單獨(dú)建立統(tǒng)一讀取入口在入口層做脫敏和行級(jí)過(guò)濾不依賴 Ranger。我在遷移時(shí)犯過(guò)的錯(cuò)就是默認(rèn) Ranger 策略對(duì) Spark 作業(yè)同樣生效結(jié)果就是開(kāi)頭說(shuō)的那場(chǎng)“上線當(dāng)天翻車”。后來(lái)我寧可多花兩天時(shí)間把讀取入口全部收斂也不再把所有希望壓在 Ranger 一個(gè)組件上。3. Spark 側(cè)需要重新補(bǔ)齊的隱私配置清單Hadoop 時(shí)代的東西能留的留完了接下來(lái)最關(guān)鍵的部分Spark 這邊需要單獨(dú)配什么。這部分我按“身份認(rèn)證、流動(dòng)數(shù)據(jù)加密、動(dòng)態(tài)脫敏、行級(jí)過(guò)濾”四個(gè)方向展開(kāi)每一項(xiàng)都是我在真實(shí)集群上驗(yàn)證過(guò)的配置邏輯。3.1 YARN 模式下把 keytab 正確交到 Spark 作業(yè)手里如果 Spark 作業(yè)跑在 YARN 上且 HDFS 開(kāi)啟了 Kerberos你必須確保作業(yè)提交時(shí)能把 keytab 和 principal 傳給 YARN。用spark-submit時(shí)標(biāo)準(zhǔn)做法是spark-submit \ --master yarn \ --deploy-mode cluster \ --keytab /etc/security/keytabs/spark.keytab \ --principal sparkEXAMPLE.COM \ --conf spark.hadoop.hadoop.security.authenticationkerberos \ --conf spark.hadoop.hdfs.client.htrace.samplernever \ --class com.example.YourApp \ your-app.jar這里--keytab和--principal是讓 YARN 在啟動(dòng) ApplicationMaster 時(shí)拿到憑證后續(xù)由 AM 繼續(xù)為 Executor 分發(fā)票據(jù)。如果你用的是 Python 作業(yè)參數(shù)一樣spark-submit \ --master yarn \ --deploy-mode cluster \ --keytab /etc/security/keytabs/spark.keytab \ --principal sparkEXAMPLE.COM \ --conf spark.hadoop.hadoop.security.authenticationkerberos \ data_process.py有一種常見(jiàn)的失敗場(chǎng)景本地kinit后跑 client 模式?jīng)]問(wèn)題但切到 cluster 模式就報(bào)GSSException: No valid credentials provided。這通常是系統(tǒng)不知道去哪個(gè) keytab 取憑證或者是 keytab 被放在了 HDFS 上且權(quán)限不對(duì)。建議 keytab 一定用獨(dú)占賬號(hào)不要塞進(jìn)公共 jar 包也不要放到 HDFS 用戶主目錄之外。如果你用的是 Spark Thrift Server則需要在spark-defaults.conf里設(shè)置spark.yarn.keytab/etc/security/keytabs/spark.keytab spark.yarn.principalsparkEXAMPLE.COM然后重啟 STS之后通過(guò) JDBC 提交的 SQL 請(qǐng)求就都有 Kerberos 身份了。3.2 Shuffle 加密、RPC 認(rèn)證和 Web UI 訪問(wèn)控制最容易忽視的流動(dòng)數(shù)據(jù)盲區(qū)Spark 作業(yè)跑起來(lái)之后真正在節(jié)點(diǎn)間流動(dòng)的數(shù)據(jù)量比 HDFS 上靜態(tài)文件多得多。尤其是 shuffle 階段每個(gè) Executor 會(huì)把中間結(jié)果寫(xiě)到本地磁盤(pán)再通過(guò)網(wǎng)絡(luò)傳給下游任務(wù)。如果你的集群是多租戶共用別人登錄到節(jié)點(diǎn)上是有機(jī)會(huì)直接讀取這些本地臨時(shí)文件的。我建議在spark-defaults.conf里至少開(kāi)啟這幾項(xiàng)# shuffle 數(shù)據(jù)加密防止中間結(jié)果被其他進(jìn)程竊取 spark.shuffle.encryption.enabledtrue # 開(kāi)啟 RPC 認(rèn)證防止偽造節(jié)點(diǎn)身份建立連接 spark.authenticatetrue # Web UI 鑒權(quán)防止未授權(quán)用戶通過(guò) 4040/18080 端口查看任務(wù)信息 spark.ui.acls.enabletrue spark.ui.view.aclsadmin spark.history.ui.acls.enabletrue很多人對(duì)spark.shuffle.encryption.enabled有疑慮覺(jué)得開(kāi)啟后性能損耗很大。我實(shí)測(cè)下來(lái)在正常的百 GB 到 TB 級(jí) shuffle 場(chǎng)景里加密帶來(lái)的 CPU 開(kāi)銷會(huì)存在但通常不會(huì)超過(guò) 10% 到 15%。對(duì)于隱私保護(hù)要求較高的集群這點(diǎn)開(kāi)銷完全值得。如果你的作業(yè)對(duì)時(shí)延極其敏感可以只對(duì)包含敏感數(shù)據(jù)表的作業(yè)開(kāi)啟而不是全局開(kāi)啟。還有一個(gè)細(xì)節(jié)spark.local.dir默認(rèn)會(huì)指向節(jié)點(diǎn)本地磁盤(pán)的臨時(shí)目錄。如果業(yè)務(wù)作業(yè)會(huì)緩存較多數(shù)據(jù)到本地磁盤(pán)建議把它掛到受控目錄并確保目錄權(quán)限只有運(yùn)行用戶能讀寫(xiě)。我在排查問(wèn)題時(shí)發(fā)現(xiàn)有些集群把spark.local.dir配成了/tmp而/tmp是大家都能進(jìn)來(lái)的地方shuffle 明文文件就這么裸奔著。3.3 動(dòng)態(tài)脫敏 UDF用 PySpark 實(shí)現(xiàn)手機(jī)號(hào)和證件號(hào)掩碼在 Spark 里做列級(jí)脫敏最穩(wěn)妥的方式不是依賴外部插件而是在數(shù)據(jù)處理鏈路里用一個(gè)標(biāo)準(zhǔn) UDF。我的習(xí)慣是建立一套公有脫敏函數(shù)包所有作業(yè)統(tǒng)一引用避免每個(gè)團(tuán)隊(duì)自己實(shí)現(xiàn)脫敏邏輯。一個(gè)簡(jiǎn)單的示例from pyspark.sql import SparkSession from pyspark.sql.functions import col, udf from pyspark.sql.types import StringType def mask_phone(phone_num): if phone_num is None: return None phone_str str(phone_num) if len(phone_str) 11: return phone_str[:3] **** phone_str[7:] return phone_str mask_phone_udf udf(mask_phone, StringType()) spark SparkSession.builder \ .appName(privacy_masking) \ .enableHiveSupport() \ .getOrCreate() users spark.sql(SELECT user_id, phone FROM risk.raw_users) masked users.select( col(user_id), mask_phone_udf(col(phone)).alias(phone_masked) ) masked.write.mode(overwrite).saveAsTable(risk.masked_users)脫敏規(guī)則看起來(lái)簡(jiǎn)單真正要命的是規(guī)則一致性。我見(jiàn)過(guò)同一個(gè)業(yè)務(wù)團(tuán)隊(duì)A 作業(yè)用“前三后四”的掩碼B 作業(yè)用“中間四位星號(hào)”的掩碼最后數(shù)據(jù)對(duì)不上審計(jì)還說(shuō)不清到底哪個(gè)是合規(guī)版本。所以脫敏函數(shù)一定要收口到公共模塊里版本號(hào)要固定誰(shuí)要改規(guī)則必須走評(píng)審。另外Python UDF 在數(shù)據(jù)量大時(shí)會(huì)有序列化開(kāi)銷性能敏感的場(chǎng)景可以用 Spark SQL 內(nèi)置函數(shù)實(shí)現(xiàn)同樣的掩碼邏輯比如SELECT user_id, CONCAT(SUBSTRING(phone, 1, 3), ****, SUBSTRING(phone, 8, 4)) AS phone_masked FROM risk.raw_users這樣既不需要注冊(cè) UDF執(zhí)行效率也更高。我的建議是能用 SQL 內(nèi)置函數(shù)解決的脫敏需求就優(yōu)先用 SQL 實(shí)現(xiàn)只有復(fù)雜規(guī)則才走 UDF。3.4 行級(jí)過(guò)濾的三種實(shí)現(xiàn)方式與各自局限行級(jí)過(guò)濾比列級(jí)脫敏更麻煩。Spark 本身沒(méi)有一套開(kāi)箱即用的“普通用戶默認(rèn)只能看自己負(fù)責(zé)數(shù)據(jù)”的機(jī)制。我在實(shí)戰(zhàn)中評(píng)估過(guò)三種做法統(tǒng)一讀表函數(shù)所有業(yè)務(wù)代碼必須調(diào)用一個(gè)公共入口來(lái)讀敏感表函數(shù)內(nèi)部根據(jù)當(dāng)前登錄用戶自動(dòng)拼過(guò)濾條件。這種方案最可控但對(duì)團(tuán)隊(duì)紀(jì)律要求高如果有人繞過(guò)入口直接用spark.read.parquet那就白搭。視圖層過(guò)濾在 Hive 中建立視圖視圖內(nèi)部通過(guò)current_user()或current_roles()判斷可見(jiàn)范圍。Spark SQL 可以查詢視圖但 DataFrame 直讀并不會(huì)經(jīng)過(guò)視圖邏輯。外部權(quán)限平臺(tái)攔截通過(guò)自研或商業(yè)數(shù)據(jù)訪問(wèn)網(wǎng)關(guān)把 Spark 作業(yè)提交階段做策略注入。成本最高適合大團(tuán)隊(duì)。我在遷移項(xiàng)目里最終選了第一種做一個(gè)強(qiáng)制入口函數(shù)形如def read_user_table(spark, user_id, table_namerisk.users): df spark.table(table_name) if owner_id in df.columns: df df.filter(fowner_id {user_id}) return df使用參數(shù)化查詢而不是字符串拼接可以有效避免 SQL 注入。同時(shí)我會(huì)在開(kāi)發(fā)規(guī)范里明確要求敏感表的讀取禁止直接使用spark.read必須走read_user_table。定時(shí)掃描作業(yè)代碼里的讀表路徑發(fā)現(xiàn)直讀行為就打回整改。聽(tīng)起來(lái)挺強(qiáng)硬但隱私保護(hù)這件事規(guī)則不硬一點(diǎn)后面出事的概率極高。4. 從 Hadoop 到 Spark 的策略遷移我的實(shí)操流程配置項(xiàng)和組件說(shuō)完了下面完整過(guò)一遍我實(shí)際執(zhí)行的遷移流程。整個(gè)流程大概持續(xù)了兩周核心不是配參數(shù)而是把權(quán)限策略從 Hive/HDFS 語(yǔ)義平滑搬到 Spark 語(yǔ)義并驗(yàn)證效果一致。4.1 第一步敏感數(shù)據(jù)分級(jí)盤(pán)點(diǎn)動(dòng)手遷移之前必須先把數(shù)據(jù)資產(chǎn)摸清楚。沒(méi)有清單就開(kāi)始配策略結(jié)果一定是漏配。我按敏感程度把數(shù)據(jù)分成三級(jí)等級(jí)典型數(shù)據(jù)存放路徑示例基本策略S1明文手機(jī)號(hào)、身份證、位置軌跡/data/risk/rawHDFS 加密區(qū) Kerberos 白名單 脫敏S2訂單號(hào)、內(nèi)部工號(hào)、業(yè)務(wù)統(tǒng)計(jì)/data/warehouseRanger 表級(jí)授權(quán) 統(tǒng)一入口S3系統(tǒng)日志、公開(kāi)文章、聚合指標(biāo)/data/public普通目錄可與 S1 物理隔離盤(pán)點(diǎn)不是 DBA 一個(gè)人在屋里做我會(huì)拉上每個(gè)業(yè)務(wù)的負(fù)責(zé)人讓他們逐個(gè)確認(rèn)“這張表到底屬于誰(shuí)、誰(shuí)能讀、脫敏標(biāo)準(zhǔn)是什么”。這個(gè)環(huán)節(jié)最花時(shí)間但也最值得。后面策略遷移和驗(yàn)證都要依賴這份清單沒(méi)有清單一切都是在碰運(yùn)氣。4.2 第二步Ranger 策略導(dǎo)出、改 service 名、再導(dǎo)入Ranger 自身提供了策略導(dǎo)入導(dǎo)出功能。Ranger Admin UI 的Settings - Export/Import可以導(dǎo)出全部服務(wù)策略也可以只導(dǎo)出 Hive 和 HDFS 相關(guān)服務(wù)。導(dǎo)出后你會(huì)拿到一份 JSON里面有 service 名稱、策略名稱、條件規(guī)則、允許/拒絕用戶列表等信息。遷移到新集群或新 Ranger 實(shí)例時(shí)不能直接把 JSON 原樣導(dǎo)入有兩個(gè)地方必須改serviceName舊集群可能是hivedev、hdfsprod新環(huán)境要對(duì)照目標(biāo) Ranger 里的 service 名逐一替換。policyId策略 ID 在新環(huán)境可能沖突建議清空后重新生成或者導(dǎo)入時(shí)用 Ranger 的覆蓋模式。引用到的用戶和組如果兩套集群的 LDAP/AD 不完全一致策略里引用的用戶組可能在新環(huán)境不存在需要同步用戶目錄。導(dǎo)入之后別急著宣布完成先用第 4.4 步的方法驗(yàn)證幾條核心策略。我自己的經(jīng)驗(yàn)是Ranger 策略遷移最容易出的問(wèn)題就是“看起來(lái)導(dǎo)入了實(shí)際因?yàn)?service 名不匹配一條都沒(méi)生效”。Ranger 的告警日志里會(huì)有大量No applicable policy類信息遷移后頭幾天要重點(diǎn)盯。4.3 第三步統(tǒng)一讀表入口別讓權(quán)限判斷散落得到處都是在 Spark 側(cè)我不想依靠每個(gè)作業(yè)各自實(shí)現(xiàn)過(guò)濾邏輯。那樣的話隱私保護(hù)就退化成“看每個(gè)開(kāi)發(fā)者的自覺(jué)程度”。我的做法是建一個(gè)內(nèi)部的 Python 包或 Java 工具類提供幾個(gè)標(biāo)準(zhǔn)化方法def read_table_with_mask(spark, database, table, user_id, mask_fieldsNone): df spark.table(f{database}.{table}) if owner_id in df.columns: df df.filter(fowner_id {user_id}) if mask_fields: for f in mask_fields: df df.withColumn(f, mask_phone_udf(f)) return df所有 Spark 作業(yè)在初始化階段強(qiáng)制指定user_id這個(gè)值從統(tǒng)一認(rèn)證服務(wù)獲取不允許自己偽造。讀取的每一個(gè)敏感表都必須通過(guò)這個(gè)封裝方法走。這樣做有三個(gè)好處第一脫敏和行級(jí)過(guò)濾規(guī)則集中在同一個(gè)地方維護(hù)第二可以在入口處加審計(jì)日志把“誰(shuí)、什么時(shí)間、讀了哪張表、過(guò)濾條件是什么”記下來(lái)第三后續(xù)如果引入更復(fù)雜的策略引擎替換入口即可不用改所有作業(yè)代碼。代價(jià)是團(tuán)隊(duì)需要改變習(xí)慣。我在推行時(shí)把原有用spark.read直讀敏感表的作業(yè)全部列了一個(gè)整改清單逐條遷到統(tǒng)一入口。這個(gè)過(guò)程痛苦但遷完之后隱私保護(hù)的可控性提升了好幾個(gè)級(jí)別。4.4 第四步回歸驗(yàn)證和審計(jì)日志核對(duì)遷移沒(méi)有驗(yàn)證就等于沒(méi)遷。我用的驗(yàn)證方法比較樸素但很管用用三個(gè)不同的測(cè)試賬號(hào)連 Spark Thrift Server分別執(zhí)行對(duì)上 S1 表和 S2 表的查詢預(yù)期是 S1 表只有白名單賬號(hào)能通過(guò)且結(jié)果里的手機(jī)號(hào)字段已被掩碼。用各執(zhí)行業(yè)務(wù)賬號(hào)跑一遍典型作業(yè)對(duì)比遷移前后的輸出結(jié)果字段數(shù)量和脫敏格式。檢查 Ranger 的審計(jì)頁(yè)面確認(rèn)來(lái)自 Spark Thrift Server 的訪問(wèn)有審計(jì)記錄。在統(tǒng)一讀取入口的日志里搜索敏感表名確認(rèn)所有讀取都經(jīng)過(guò)入口沒(méi)有直讀路徑殘留。審計(jì)日志這塊很容易被忽略。Hadoop 時(shí)代我們習(xí)慣依賴 Ranger 審計(jì)來(lái)追溯誰(shuí)看了什么但 Spark 編程直讀模式下Ranger 審計(jì)可能會(huì)缺事件。所以我會(huì)明確劃分HS2/STS 上的 SQL 請(qǐng)求由 Ranger 審計(jì)兜底Spark 編程作業(yè)的讀取行為由統(tǒng)一入口審計(jì)兜底。兩條審計(jì)鏈路合起來(lái)才能拼出一張相對(duì)完整的訪問(wèn)全景圖。5. 上線后我踩過(guò)的三個(gè)真實(shí)的坑配置遷移完成不等于萬(wàn)事大吉。真正上線跑流量之后我陸續(xù)踩了幾個(gè)坑每一個(gè)都花了挺大力氣才排查清楚。寫(xiě)出來(lái)給大家避雷。5.1 坑一Spark 本地臨時(shí)目錄里躺著明文 shuffle 數(shù)據(jù)第一次開(kāi)通加密區(qū)后我以為敏感數(shù)據(jù)在集群上已經(jīng)全程加密了。直到有一次排查磁盤(pán)故障登錄到數(shù)據(jù)節(jié)點(diǎn)上看了看/tmp/spark-xxxx下的文件發(fā)現(xiàn) shuffle 產(chǎn)生的中間文件竟然全是明文。原因很簡(jiǎn)單spark.local.dir默認(rèn)在節(jié)點(diǎn)本地磁盤(pán)這部分目錄根本不在 HDFS 加密區(qū)范圍內(nèi)KMS 加密對(duì)它沒(méi)有任何作用。要解決這個(gè)問(wèn)題不是簡(jiǎn)單開(kāi)一個(gè)開(kāi)關(guān)就行需要組合操作限制節(jié)點(diǎn)登錄權(quán)限、把spark.local.dir從公共臨時(shí)目錄移到具備嚴(yán)格權(quán)限的專用目錄、開(kāi)啟spark.shuffle.encryption.enabledtrue。如果集群里已經(jīng)有敏感數(shù)據(jù)作業(yè)在跑建議立刻檢查所有節(jié)點(diǎn)的 Spark 臨時(shí)目錄里是否有 S1 級(jí)數(shù)據(jù)殘留再?zèng)Q定是否需要重跑歷史作業(yè)。檢查命令很簡(jiǎn)單find /tmp -maxdepth 3 -user spark -type f 2/dev/null | head -50如果這些文件屬于敏感作業(yè)且未加密就可以認(rèn)為存在一次隱私保護(hù)事故至少要把相關(guān)內(nèi)容記錄到審計(jì)事件里。5.2 坑二Spark UI 把 SQL 明文、路徑和文件列表全暴露了Spark 的 Web UI 和 History Server 是信息泄露高發(fā)區(qū)。默認(rèn)情況下只要知道節(jié)點(diǎn) IP 和端口比如 4040、18080任何人都能打開(kāi)頁(yè)面看到作業(yè)列表、SQL 查詢文本、輸入數(shù)據(jù)路徑、甚至部分執(zhí)行計(jì)劃。我在遷移時(shí)曾遇到一個(gè)測(cè)試賬號(hào)直接訪問(wèn)了生產(chǎn)集群的 History Server 頁(yè)面把某個(gè)離線作業(yè)里的敏感表路徑和 SQL 條件全部看到了。這類問(wèn)題可以通過(guò)配置收斂spark.ui.acls.enabletrue spark.admin.aclsadmin,sparkadmin spark.ui.view.aclssparkadmin spark.history.ui.acls.enabletrue spark.eventLog.dir/data/sensitive/spark-logs這里還多提一點(diǎn)spark.eventLog.dir建議要么設(shè)置到 HDFS 加密區(qū)要么配合嚴(yán)格目錄權(quán)限因?yàn)?event log 里會(huì)記錄完整的執(zhí)行信息包括查詢語(yǔ)句。日志本身是隱私保護(hù)的一部分別把它排除在保護(hù)范圍之外。5.3 坑三審計(jì)日志看不到“讀了哪一列”只能靠自查第三個(gè)坑是審計(jì)粒度。Ranger 的審計(jì)可以記錄 Hive 表級(jí)別訪問(wèn)但真正到了 Spark 作業(yè)它記錄不到這個(gè)作業(yè)到底投影了哪些列、過(guò)濾條件是什么。有個(gè)業(yè)務(wù)方反饋說(shuō)“我們只是跑了報(bào)表沒(méi)有讀敏感列”可當(dāng)我想從審計(jì)系統(tǒng)里找到證據(jù)來(lái)確認(rèn)時(shí)發(fā)現(xiàn)壓根沒(méi)有列級(jí)訪問(wèn)記錄。這件事讓我很被動(dòng)。后來(lái)我徹底接受了現(xiàn)實(shí)Spark 作業(yè)的列級(jí)訪問(wèn)審計(jì)需要靠統(tǒng)一入口自己打點(diǎn)。在read_table_with_mask函數(shù)里把傳入的表名、字段列表、用戶 ID、作業(yè) ID、時(shí)間戳全部寫(xiě)入 Kafka 或日志文件再對(duì)接企業(yè)日志平臺(tái)才算有了真正可追溯的列級(jí)審計(jì)鏈。用偽代碼表達(dá)這個(gè)思路def audit_log(user_id, database, table, fields, app_id): log_payload { user: user_id, database: database, table: table, fields: fields, app_id: app_id, ts: current_time() } kafka_producer.send(data_access_audit, log_payload)最初我覺(jué)得這樣很啰嗦但從隱私保護(hù)的角度看沒(méi)有審計(jì)的權(quán)限控制等于沒(méi)有因?yàn)槌隽藛?wèn)題你連排查的依據(jù)都沒(méi)有。6. 日常巡檢隱私保護(hù)配置不是設(shè)完就結(jié)束的遷移完成、坑也填完之后我還保留了一套巡檢機(jī)制用來(lái)防止配置隨著版本升級(jí)、作業(yè)調(diào)整而悄悄失效。這里分享幾條我現(xiàn)在實(shí)際在做的巡檢項(xiàng)。我大概每?jī)芍茏鲆惠啓z查第一刷新 Ranger 策略列表和上輪備份做對(duì)比確認(rèn)沒(méi)有未評(píng)審的策略變更第二掃描 Spark 事件日志目錄和歷史服務(wù)訪問(wèn)日志看看有沒(méi)有異常用戶訪問(wèn)記錄第三用測(cè)試賬號(hào)在測(cè)試環(huán)境嘗試讀取幾條 S1 表路徑確認(rèn)加密區(qū)、ACL、脫敏入口都還在正常工作第四核對(duì) keytab 有效期和 KMS 服務(wù)狀態(tài)避免因?yàn)槠睋?jù)過(guò)期導(dǎo)致業(yè)務(wù)突然中斷。另外我在調(diào)度平臺(tái)上掛了一個(gè)每日腳本掃描所有 Spark 作業(yè)提交參數(shù)檢查是否帶了--keytab和--principal以及是否存在繞過(guò)統(tǒng)一入口直接spark.read的代碼特征。掃描結(jié)果每天推送到運(yùn)維群里有問(wèn)題就人工介入。這些步驟看起來(lái)瑣碎但隱私保護(hù)本來(lái)就不是上線當(dāng)天做一次審計(jì)就完事的事情。我自己在踩過(guò)那幾次坑之后最大的感受是把配置文檔寫(xiě)得再厚都不如定期跑一遍真實(shí)檢查來(lái)得可靠。