去年我把一套跑了三年的 Hadoop 離線平臺(tái)逐步遷到 Spark 上做實(shí)時(shí)計(jì)算時(shí)原本以為 Hive 和 HDFS 上已經(jīng)配好的 Ranger 權(quán)限策略能直接繼承過去結(jié)果上線當(dāng)天就有業(yè)務(wù)同學(xué)通過 Spark SQL 讀到了權(quán)限表之外的明文手機(jī)號(hào)。那一刻我才真正意識(shí)到在大數(shù)據(jù)平臺(tái)里隱私保護(hù)配置從來(lái)不是“配一次就一勞永逸”的事從 Hadoop 遷移到 Spark幾乎等于把整套保護(hù)體系重新梳理一遍。這篇內(nèi)容就是記錄我在實(shí)際切換過程中的完整思路和配置清單包括哪些 Hadoop 時(shí)代的組件必須保留、Spark 側(cè)需要補(bǔ)充哪些隱私保護(hù)配置、策略遷移時(shí)如何驗(yàn)證一致性以及我踩過的幾個(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ì)落到“打開文件、讀取塊、返回記錄”這條路徑上。因此權(quán)限控制可以非常自然地做在 HDFS 層、Metastore 層或者 HS2 入口只要把文件的 ACL、目錄的屬主、Hive 表的授權(quán)策略布控好基本就能覆蓋絕大多數(shù)訪問場(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é)果寫到了哪里存儲(chǔ)層幾乎感知不到。這里就出現(xiàn)了一個(gè)很微妙的入口空缺Spark 數(shù)據(jù)計(jì)算的合法性更多要依賴任務(wù)提交時(shí)的身份、任務(wù)運(yùn)行時(shí)的訪問請(qǐng)求、以及結(jié)果輸出位置來(lái)管控而不是傳統(tǒng)意義上“誰(shuí)摸到了這個(gè)文件”。舉個(gè)我在實(shí)際遷移中遇到的例子Hive 用戶通過 JDBC 查詢一張表時(shí)Ranger 的 Hive 插件會(huì)攔截 SQL判斷用戶是否有 SELECT 權(quán)限。但同一個(gè)用戶用 PySpark 的spark.table(db.sensitive_table)直讀時(shí)如果 Spark 沒有接入同一套授權(quán)插件這條路徑就可能繞過 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í)都能攔。問題在于Spark 并不必須走 HiveServer2。常見的 Spark SQL 訪問路徑有三條Spark Thrift ServerSTS方式把 Spark 當(dāng)作 HiveServer2 的替代品客戶端通過 JDBC 提交 SQL。這條路徑理論上可以復(fù)用 Ranger 對(duì) Hive 的插件但需要單獨(dú)確認(rèn)插件是否支持 STS以及 SQL 解析是否經(jīng)過相同的 Hook。DataFrame 編程方式spark.read.parquet(/user/data/sensitive)完全繞過 Hive 語(yǔ)義層Ranger 的 Hive 插件根本看不到這個(gè)請(qǐng)求。Catalog 方式通過 V2 DataSource API 或自定義 Catalog 讀取文件權(quán)限控制取決于實(shí)現(xiàn)和 Hive 策略無(wú)關(guān)。我見過不少團(tuán)隊(duì)在遷移時(shí)忽略了這個(gè)差別認(rèn)為 Ranger 策略已經(jīng)覆蓋全部數(shù)據(jù)訪問結(jié)果 Spark 作業(yè)全都在“裸奔”。所以第一條建議就是先把你的業(yè)務(wù)訪問方式排查一遍分清哪些是走 STS、哪些是編程直讀。對(duì)編程直讀的部分別幻想 Ranger 能全兜住要在應(yīng)用層或統(tǒng)一讀取入口補(bǔ)控制。1.3 先分清靜態(tài)數(shù)據(jù)保護(hù)和流動(dòng)數(shù)據(jù)保護(hù)才不會(huì)漏配隱私保護(hù)配置最容易出的問題是只盯著“存在磁盤上的數(shù)據(jù)”卻忽略了“在作業(yè)運(yùn)行過程中流動(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 緩存到本地磁盤的部分、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 訪問控制。很多團(tuán)隊(duì)只做了 HDFS 加密認(rèn)為“磁盤加密 數(shù)據(jù)加密”這其實(shí)只能覆蓋靜態(tài)維度。真正的隱私保護(hù)斷檔幾乎都出現(xiàn)在流動(dòng)數(shù)據(jù)上。后面第 3 章我會(huì)把這些配置項(xiàng)逐個(gè)展開。2. Hadoop 時(shí)代留下的三件套哪些必須保留別一提到遷移就覺得舊組件全要扔掉。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)策略沒配好它照樣可以訪問所有表。很多團(tuán)隊(duì)把 Kerberos 當(dāng)成隱私保護(hù)的全部這是理解偏差。到了 Spark 階段Kerberos 的價(jià)值不僅沒有減弱反而更關(guān)鍵。Spark 作業(yè)要訪問受保護(hù)的 HDFS必須先拿到有效票據(jù)要提交到 YARN 并運(yùn)行在集群模式也需要把 principal 和 keytab 交給 YARN 來(lái)?yè)Q取下一個(gè)階段的票據(jù)。我在遷移中最大的感受是Kerberos 配置本身沒變但 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è)凌晨莫名其妙開始報(bào)認(rèn)證失敗。Hadoop 時(shí)代的 MapReduce 作業(yè)短平快跑完就結(jié)束幾乎不存在這個(gè)問題Spark 的長(zhǎng)任務(wù)直接把這個(gè)問題暴露出來(lái)了。然后是 keytab 的權(quán)限管控。keytab 文件本質(zhì)上就是身份憑證誰(shuí)拿到它誰(shuí)就能以對(duì)應(yīng)身份提交作業(yè)。我見過有的團(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ì)落盤數(shù)據(jù)做加密對(duì)上層應(yīng)用完全透明。這意味著 Spark 讀寫加密區(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ū)# 通過 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ù)”的泄露問題比如磁盤被拔走、備份介質(zhì)丟失、未授權(quán)用戶直接讀數(shù)據(jù)塊的場(chǎng)景。它并不能阻止一個(gè)擁有合法 Kerberos 憑證的 Spark 作業(yè)將數(shù)據(jù)讀取后落盤到普通目錄也不能阻止作業(yè)把數(shù)據(jù)計(jì)算結(jié)果顯示在日志里。所以我在遷移方案中把它的定位設(shè)為“基礎(chǔ)防線”而不是“唯一防線”。另外還有一個(gè)容易忽略的點(diǎn)KMS 本身要高可用密鑰輪換策略要提前定好。否則一旦 KMS 節(jié)點(diǎn)出問題所有加密區(qū)數(shù)據(jù)的讀寫都會(huì)受阻Spark 作業(yè)會(huì)大面積失敗。這不是 Spark 的配置問題但遷移時(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è)表”的訪問。但在 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ù)上游需要通過 Hive SQL 查看敏感表可以用 Ranger 的 Masking 功能對(duì)某些列做動(dòng)態(tài)脫敏。但這么做的前提是訪問路徑確實(shí)經(jīng)過 Ranger 插件使用前最好實(shí)測(cè)驗(yàn)證。編程讀取凡是spark.read、spark.table之類的代碼路徑單獨(dú)建立統(tǒng)一讀取入口在入口層做脫敏和行級(jí)過濾不依賴 Ranger。我在遷移時(shí)犯過的錯(cuò)就是默認(rèn) Ranger 策略對(duì) Spark 作業(yè)同樣生效結(jié)果就是開頭說(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í)過濾”四個(gè)方向展開每一項(xiàng)都是我在真實(shí)集群上驗(yàn)證過的配置邏輯。3.1 YARN 模式下把 keytab 正確交到 Spark 作業(yè)手里如果 Spark 作業(yè)跑在 YARN 上且 HDFS 開啟了 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有一種常見的失敗場(chǎng)景本地kinit后跑 client 模式?jīng)]問題但切到 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之后通過 JDBC 提交的 SQL 請(qǐng)求就都有 Kerberos 身份了。3.2 Shuffle 加密、RPC 認(rèn)證和 Web UI 訪問控制最容易忽視的流動(dòng)數(shù)據(jù)盲區(qū)Spark 作業(yè)跑起來(lái)之后真正在節(jié)點(diǎn)間流動(dòng)的數(shù)據(jù)量比 HDFS 上靜態(tài)文件多得多。尤其是 shuffle 階段每個(gè) Executor 會(huì)把中間結(jié)果寫到本地磁盤再通過網(wǎng)絡(luò)傳給下游任務(wù)。如果你的集群是多租戶共用別人登錄到節(jié)點(diǎn)上是有機(jī)會(huì)直接讀取這些本地臨時(shí)文件的。我建議在spark-defaults.conf里至少開啟這幾項(xiàng)# shuffle 數(shù)據(jù)加密防止中間結(jié)果被其他進(jìn)程竊取 spark.shuffle.encryption.enabledtrue # 開啟 RPC 認(rèn)證防止偽造節(jié)點(diǎn)身份建立連接 spark.authenticatetrue # Web UI 鑒權(quán)防止未授權(quán)用戶通過 4040/18080 端口查看任務(wù)信息 spark.ui.acls.enabletrue spark.ui.view.aclsadmin spark.history.ui.acls.enabletrue很多人對(duì)spark.shuffle.encryption.enabled有疑慮覺得開啟后性能損耗很大。我實(shí)測(cè)下來(lái)在正常的百 GB 到 TB 級(jí) shuffle 場(chǎng)景里加密帶來(lái)的 CPU 開銷會(huì)存在但通常不會(huì)超過 10% 到 15%。對(duì)于隱私保護(hù)要求較高的集群這點(diǎn)開銷完全值得。如果你的作業(yè)對(duì)時(shí)延極其敏感可以只對(duì)包含敏感數(shù)據(jù)表的作業(yè)開啟而不是全局開啟。還有一個(gè)細(xì)節(jié)spark.local.dir默認(rèn)會(huì)指向節(jié)點(diǎn)本地磁盤的臨時(shí)目錄。如果業(yè)務(wù)作業(yè)會(huì)緩存較多數(shù)據(jù)到本地磁盤建議把它掛到受控目錄并確保目錄權(quán)限只有運(yù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ī)則一致性。我見過同一個(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ì)有序列化開銷性能敏感的場(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í)過濾的三種實(shí)現(xiàn)方式與各自局限行級(jí)過濾比列級(jí)脫敏更麻煩。Spark 本身沒有一套開箱即用的“普通用戶默認(rèn)只能看自己負(fù)責(zé)數(shù)據(jù)”的機(jī)制。我在實(shí)戰(zhàn)中評(píng)估過三種做法統(tǒng)一讀表函數(shù)所有業(yè)務(wù)代碼必須調(diào)用一個(gè)公共入口來(lái)讀敏感表函數(shù)內(nèi)部根據(jù)當(dāng)前登錄用戶自動(dòng)拼過濾條件。這種方案最可控但對(duì)團(tuán)隊(duì)紀(jì)律要求高如果有人繞過入口直接用spark.read.parquet那就白搭。視圖層過濾在 Hive 中建立視圖視圖內(nèi)部通過current_user()或current_roles()判斷可見范圍。Spark SQL 可以查詢視圖但 DataFrame 直讀并不會(huì)經(jīng)過視圖邏輯。外部權(quán)限平臺(tái)攔截通過自研或商業(yè)數(shù)據(jù)訪問網(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ì)在開發(fā)規(guī)范里明確要求敏感表的讀取禁止直接使用spark.read必須走read_user_table。定時(shí)掃描作業(yè)代碼里的讀表路徑發(fā)現(xiàn)直讀行為就打回整改。聽起來(lái)挺強(qiáng)硬但隱私保護(hù)這件事規(guī)則不硬一點(diǎn)后面出事的概率極高。4. 從 Hadoop 到 Spark 的策略遷移我的實(shí)操流程配置項(xiàng)和組件說(shuō)完了下面完整過一遍我實(shí)際執(zhí)行的遷移流程。整個(gè)流程大概持續(xù)了兩周核心不是配參數(shù)而是把權(quán)限策略從 Hive/HDFS 語(yǔ)義平滑搬到 Spark 語(yǔ)義并驗(yàn)證效果一致。4.1 第一步敏感數(shù)據(jù)分級(jí)盤點(diǎn)動(dòng)手遷移之前必須先把數(shù)據(jù)資產(chǎn)摸清楚。沒有清單就開始配策略結(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)日志、公開文章、聚合指標(biāo)/data/public普通目錄可與 S1 物理隔離盤點(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)證都要依賴這份清單沒有清單一切都是在碰運(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 策略遷移最容易出的問題就是“看起來(lái)導(dǎo)入了實(shí)際因?yàn)?service 名不匹配一條都沒生效”。Ranger 的告警日志里會(huì)有大量No applicable policy類信息遷移后頭幾天要重點(diǎn)盯。4.3 第三步統(tǒng)一讀表入口別讓權(quán)限判斷散落得到處都是在 Spark 側(cè)我不想依靠每個(gè)作業(yè)各自實(shí)現(xiàn)過濾邏輯。那樣的話隱私保護(hù)就退化成“看每個(gè)開發(fā)者的自覺程度”。我的做法是建一個(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è)敏感表都必須通過這個(gè)封裝方法走。這樣做有三個(gè)好處第一脫敏和行級(jí)過濾規(guī)則集中在同一個(gè)地方維護(hù)第二可以在入口處加審計(jì)日志把“誰(shuí)、什么時(shí)間、讀了哪張表、過濾條件是什么”記下來(lái)第三后續(xù)如果引入更復(fù)雜的策略引擎替換入口即可不用改所有作業(yè)代碼。代價(jià)是團(tuán)隊(duì)需要改變習(xí)慣。我在推行時(shí)把原有用spark.read直讀敏感表的作業(yè)全部列了一個(gè)整改清單逐條遷到統(tǒng)一入口。這個(gè)過程痛苦但遷完之后隱私保護(hù)的可控性提升了好幾個(gè)級(jí)別。4.4 第四步回歸驗(yàn)證和審計(jì)日志核對(duì)遷移沒有驗(yàn)證就等于沒遷。我用的驗(yàn)證方法比較樸素但很管用用三個(gè)不同的測(cè)試賬號(hào)連 Spark Thrift Server分別執(zhí)行對(duì)上 S1 表和 S2 表的查詢預(yù)期是 S1 表只有白名單賬號(hào)能通過且結(jié)果里的手機(jī)號(hào)字段已被掩碼。用各執(zhí)行業(yè)務(wù)賬號(hào)跑一遍典型作業(yè)對(duì)比遷移前后的輸出結(jié)果字段數(shù)量和脫敏格式。檢查 Ranger 的審計(jì)頁(yè)面確認(rèn)來(lái)自 Spark Thrift Server 的訪問有審計(jì)記錄。在統(tǒng)一讀取入口的日志里搜索敏感表名確認(rèn)所有讀取都經(jīng)過入口沒有直讀路徑殘留。審計(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ì)完整的訪問全景圖。5. 上線后我踩過的三個(gè)真實(shí)的坑配置遷移完成不等于萬(wàn)事大吉。真正上線跑流量之后我陸續(xù)踩了幾個(gè)坑每一個(gè)都花了挺大力氣才排查清楚。寫出來(lái)給大家避雷。5.1 坑一Spark 本地臨時(shí)目錄里躺著明文 shuffle 數(shù)據(jù)第一次開通加密區(qū)后我以為敏感數(shù)據(jù)在集群上已經(jīng)全程加密了。直到有一次排查磁盤故障登錄到數(shù)據(jù)節(jié)點(diǎn)上看了看/tmp/spark-xxxx下的文件發(fā)現(xiàn) shuffle 產(chǎn)生的中間文件竟然全是明文。原因很簡(jiǎn)單spark.local.dir默認(rèn)在節(jié)點(diǎn)本地磁盤這部分目錄根本不在 HDFS 加密區(qū)范圍內(nèi)KMS 加密對(duì)它沒有任何作用。要解決這個(gè)問題不是簡(jiǎn)單開一個(gè)開關(guān)就行需要組合操作限制節(jié)點(diǎn)登錄權(quán)限、把spark.local.dir從公共臨時(shí)目錄移到具備嚴(yán)格權(quán)限的專用目錄、開啟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任何人都能打開頁(yè)面看到作業(yè)列表、SQL 查詢文本、輸入數(shù)據(jù)路徑、甚至部分執(zhí)行計(jì)劃。我在遷移時(shí)曾遇到一個(gè)測(cè)試賬號(hào)直接訪問了生產(chǎn)集群的 History Server 頁(yè)面把某個(gè)離線作業(yè)里的敏感表路徑和 SQL 條件全部看到了。這類問題可以通過配置收斂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í)別訪問但真正到了 Spark 作業(yè)它記錄不到這個(gè)作業(yè)到底投影了哪些列、過濾條件是什么。有個(gè)業(yè)務(wù)方反饋說(shuō)“我們只是跑了報(bào)表沒有讀敏感列”可當(dāng)我想從審計(jì)系統(tǒng)里找到證據(jù)來(lái)確認(rèn)時(shí)發(fā)現(xiàn)壓根沒有列級(jí)訪問記錄。這件事讓我很被動(dòng)。后來(lái)我徹底接受了現(xiàn)實(shí)Spark 作業(yè)的列級(jí)訪問審計(jì)需要靠統(tǒng)一入口自己打點(diǎn)。在read_table_with_mask函數(shù)里把傳入的表名、字段列表、用戶 ID、作業(yè) ID、時(shí)間戳全部寫入 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)最初我覺得這樣很啰嗦但從隱私保護(hù)的角度看沒有審計(jì)的權(quán)限控制等于沒有因?yàn)槌隽藛栴}你連排查的依據(jù)都沒有。6. 日常巡檢隱私保護(hù)配置不是設(shè)完就結(jié)束的遷移完成、坑也填完之后我還保留了一套巡檢機(jī)制用來(lái)防止配置隨著版本升級(jí)、作業(yè)調(diào)整而悄悄失效。這里分享幾條我現(xiàn)在實(shí)際在做的巡檢項(xiàng)。我大概每?jī)芍茏鲆惠啓z查第一刷新 Ranger 策略列表和上輪備份做對(duì)比確認(rèn)沒有未評(píng)審的策略變更第二掃描 Spark 事件日志目錄和歷史服務(wù)訪問日志看看有沒有異常用戶訪問記錄第三用測(cè)試賬號(hào)在測(cè)試環(huán)境嘗試讀取幾條 S1 表路徑確認(rèn)加密區(qū)、ACL、脫敏入口都還在正常工作第四核對(duì) keytab 有效期和 KMS 服務(wù)狀態(tài)避免因?yàn)槠睋?jù)過期導(dǎo)致業(yè)務(wù)突然中斷。另外我在調(diào)度平臺(tái)上掛了一個(gè)每日腳本掃描所有 Spark 作業(yè)提交參數(shù)檢查是否帶了--keytab和--principal以及是否存在繞過統(tǒng)一入口直接spark.read的代碼特征。掃描結(jié)果每天推送到運(yùn)維群里有問題就人工介入。這些步驟看起來(lái)瑣碎但隱私保護(hù)本來(lái)就不是上線當(dāng)天做一次審計(jì)就完事的事情。我自己在踩過那幾次坑之后最大的感受是把配置文檔寫得再厚都不如定期跑一遍真實(shí)檢查來(lái)得可靠。