DevOps實踐-白名單二三事

bean_53發表於2017-04-19
dev

為何加白名單是一件痛苦的事？

白名單的需求，即我們的部分應用，出於資料的敏感性與安全性，需要讓指定的外包公司能訪問，但其他外網使用者不能訪問的一種需求。
需求已明確，再看下我們之前的架構是否是天然支援這種需求。
一個域名接入阿里環境的應用，無非走VIP或者是統一接入層。

VIP：

screenshot.png
內網給機器間呼叫，辦公網給辦公環境訪問，網際網路給所有外部使用者訪問，跨域給7網分離的網路間呼叫，可以看到VIP並不天然支援外包公司的精細接入需求。

統一接入層：

最早統一接入層只有主站叢集，給所有外部使用者訪問，只是隨著架構的演進才有了辦公網的統一接入層，最近又有了以環境和BU為維度的統一接入層，早先的統一接入層也並不天然支援外包公司的精細接入需求。
為什麼給外包公司加白名單那麼痛苦，根源在於我們的架構天然就不支援這種模式，而任何的特例都要付出額外的代價，隨著加白名單的需求越來越多，痛苦和風險就越大。
看一下痛苦在哪裡，需求是外包公司員工提出的，接到這個需求的可能是CRM的運營同學，而運營同學直接找PE又說不清需求（搞不清楚要在哪個應用加白名單），運營同學就會先找開發轉述這個需求，開發搞清楚需求後，再找PE實現這個需求，鏈路很長，中間可能會有資訊的丟失，最後弄完了還得讓外包員工測試，黃花菜都涼了。

早期有哪些白名單接入方式？

VPN方式：

  • 背景：外包公司已經按照阿里IT要求，採購對應的VPN裝置，並已經完成網路除錯。
  • 優點：接入後幾乎不需要額外再做什麼，外包公司憑藉VPN裝置訪問內網應用，運營開發可能無感。
  • 缺點：週期長，至少得一個月，因業務需求外包公司發現不能訪問一般等不了這麼長時間。

VIP方式:

  • 背景：這種方式應用一般是個辦公網環境的應用，辦公網的vip，之前只能辦公網環境訪問，需要接外包環境就需要在vip上增加外包白名單，做一個加法。
  • 優點：只需要針對vip。
  • 缺點：網工需要介入增加vip白名單，vip過於分散。

ACL方式:

  • 背景：這種方式應用一般是個網際網路環境的應用，網際網路的vip或者走主站叢集統一接入層，若只有外包能訪問，需要在應用的nginx層做一層白名單控制，白名單的ip可以訪問，其他全部拒絕，做一個減法。
  • 優點：只需要針對應用的nginx配置。
  • 缺點：開發或者PE需要做應用變更，應用過於分散。

以上也可以參看米芾的文件：外包公司網路接入。

如何解決這個痛點？

從上述的接入方式看出，若要優化加白名單這個功能，只能從這三個方面去考慮了，VPN方式，對運營開發PE來說都挺好，但外包公司不接受，實時性不夠，基本沒太大優化空間，下面說說vip和acl這兩種方式的優化。

ACL優化：

先來看看之前的變更模式，做ACL變更，白名單一般儲存在單獨的一個檔案如CRM_IPs或者直接寫在nginx-proxy.conf，我們需要批量把需要增加的IPs新增到nginx的allow配置項上，具體的可以看少謙的文件：關於nginx的訪問限制(allow&deny)，操作可以看時序的文件：devops系列：如何給應用加nginx白名單（7層）。
如果是黑屏，需要改配置，然後推送所有機器，再更新基線；如果是白屏，需要變更配置，然後做一次釋出，總體來講模式有點重，消耗時間也不短。
優化思路，既然釋出的模式有點重，那我們看看是否能去掉髮布走推送模式，按應用維度把新增的白名單推送一次，如果能實現，可以把變更時間控制在幾秒內，而開發也無需清楚到底要改什麼檔案，無腦推白名單就好。

再來看看如何實現，既然是推送，首先想到中介軟體的diamond有實時推送的功能，比如限流的配置，都是實時起效的，這塊可以借鑑；其次推完了還得實時起效，白名單配置在nginx上，nginx本身不能動態識別，但是lua模組卻可以。有了這兩點，這個功能基本有戲。

以下是當時在做這個優化的時候記錄的一些點供大家參考，雖然最終的優化方案並不是這個，但這個方案還是有值得借鑑的地方，沒準下次優化會用到。

  • 前端設計：這塊比較簡單，只需要一個應用的下拉框和白名單的資料框，白名單可能是單個的ip也可能是ip段，前端可以先檢查ip或者ip段是否合理，實現增刪改查。
  • 後端設計：後端的邏輯並不多，如果前端沒有做檢驗的工作，那這還塊也需要放在後端功能實現，另外還需要對ip段做解析，因為lua模組還不支援ip段的解析，所以需要在服務端將ip段解析成ip再推送到應用。關於ip段的解析，如果是python，參考時序的文件：工程師奇技淫巧-IP段轉換CIDR(python篇)；如果是java，可以考慮用這個包：org.apache.commons.net.util.SubnetUtils，增刪改查時再考慮下重複ip的去重。
  • diamond推送：這塊遇到的問題，如果白名單數量較多，尤其是ip段解析後生成大量ip，這個ip會以url的引數形式進行傳送，而這個段是有可能超過diamond能推送的範疇，印象中diamond最多推送是1M的資料，如果超過了會做截斷，這塊其實還需要優化。
  • 應用端改造：改造包括去掉之前的白名單配置，增加lua配置，參考文件可以看這一篇：nginx ip access limit with lua。有興趣的還可以申請日常機器（10.125.30.123）的許可權，所有的配置都在/home/admin/cai/conf裡。其中diamond.conf配置了diamond_server和傳入的ip如何對應到access_limit.lua，diamond推送資料的路徑配置在/home/admin/cai/conf/diamond，/home/admin/cai/conf/diamond/snapshot/DEFAULT_GROUP/com.ali.white.ip是推送過來的白名單IPs。可能存在的問題是如果白名單數量多lua遍歷白名單對nginx效能造成影響。對lua有興趣的可以參考金九的這個文件：tengine+lua開發。

整體再說下這個功能：前端利用diamond推送白名單到應用的監聽端，監聽端配置了tengine的監聽規則，tengine的lua模組實時遍歷diamond推送過來的白名單IPs進行訪問的過濾（只需推送配置，不需要重啟服務），從而不需要進行釋出就可以實現動態推送白名單功能。這個功能從前端到後端已完全實現，鑑於篇幅，程式碼就不展示了。這個功能簡化了白名單的變更，只要有許可權，不懂技術的也能操作，實時性也很好，但是還有一定的改造成本，尤其是lua的改造。

VIP優化：

再來看看vip優化，如果單純還走vip，優化空間不大，只能是網工的工具改進，比如以前是手動新增，後續是自動化的任務新增，但是對於提工單的人來說還是比較痛苦。關鍵的問題在於每個應用有不同的vip，每個vip都有白名單配置，如果能把這些vip收斂掉，優化空間巨大。

替代方案：統一接入層。想一下我們的需求，辦公網環境，而且外包公司可以訪問，那這個統一接入層就需要是一個辦公網的統一接入層，外加白名單需求讓外包公司訪問，而這個白名單IPs可以在辦公網統一接入層的vip上收斂掉。

關於辦公網統一接入層的概念和接入，請看青索的文件：辦公網統一接入層接入規範。

關於在辦公網統一接入層基礎上增加白名單的，可以參考楊儀的文件：DevOps那些事兒——談應用VIP架構的演進。

變更需求請參考：淘系應用通過接入統一接入層以支援https。

看下改造成本，一是去除應用端白名單配置，二是接入帶白名單功能的統一接入層（crm.wagbridge.alibabacorp.com），新增白名單隻需要針對同一個的vip做一次變更。

整體來看，這個優化方案是相對最優，儘管也有不完美的地方，如統一白名單之後，所有應用的白名單是一致的，精細化管控上並沒有上個優化方案那麼完美，不過瑕不掩瑜，整體看還是是最優的。


相關文章